*dusts off blog*
Okay, I absolutely have to write something about Axiom Verge. The vagueness and secretiveness of this game’s story has been eating at me pretty hard.
If you want a good summary of the story, go check out this NeoGAF thread. I want to address some of the things that he didn’t.
Check it after the jump.
Continue reading
Today, Harold Ramis passed away. Now, many folks who know me know that I am quite a fan of the Ghostbusters, and that original movie is where most people’s familiarity with Ramis lies.
Except, well, those of us who know better know his impact on comedy throughout the 80’s and onward.
In many ways, the way he wrote comedy in his films informed my own sense of humor over the years, much like the way that the entirely fictional character of Dr. Egon Spengler informed my own disposition toward learning and science.
I’ve always tried to work on the good one liner and good dialogue in my own speech and writing, and I can’t say that I haven’t been influenced by Ramis in that respect.
So, here’s to you, sir. We’ll still have your wonderful films even though you’re no longer with us.
I haven’t updated this in a while since I’ve been working on my thesis and papers. In that sense, I’m going to do what the TV networks do: run some repeats! This is an adaptation of something I wrote about closures (in CS) some years ago.
Every time I tell myself “I’m going to finally understand closures today!” and I make the mistake of going and reading about them, my brain seizes up like an overheating car engine.
I think it’s mainly to do with the way that the writers of these articles write the definition of “closure”: it is way too obtuse. After reading these things repeatedly, I think–I think–the simplified definition is “A function that is created at runtime that, in addition to defining its own local variables, contains references to the variables of its creator’s local scope. This created function can continue to use and alter these variables once its creator goes away.”
I think that’s right. It’s certainly better than this: “A function that can refer to and alter the values of bindings established by binding forms that textually include the function definition.” That’s from here. I keep reading that over and over and it’s only very slowly making sense to me.
But why do closures break my brain (and possibly yours)?
First off, the name. A closure, in mathematics, is a concept/object in set theory. This is the first thing I think of when I hear the term, not this magical function-object-thing.
Secondly, I think it’s because of the kinds of systems I’m used to working on: the very environment that you need in place to make a closure work is utterly alien to me. Specifically, the ability to create functions from thin air; i.e., functions as a first-class object. More modern languages have this feature, but when you’ve spent as long as I have not using functional languages, it’s sort of mind bending.
(Even though Javascript has closures, so therefore I’ve worked in that sort of environment. But that’s irrelevant.)
That is, to fully understand closures, you must (mostly) eschew the traditional stack-oriented method of tracking local variables.
Consider the following example implementation:
Instead of allocating space for local variables on the stack when a function is called, like what you’d normally do in stack-based environments, allocate them on the heap, with some sort of reference count or other garbage collecting scheme.
When a closure is created in this environment, it’ll hold a reference to these heap variables, which gives that unique trait of persistence once the creator’s stack frame is popped off. You’ll also get the ability to create multiple closures with multiple calls to this creator function, each with their own copies of this environment. If no closures are created, these variables will just be garbage-collected once the potential creator function returns.
It’s that last part that’s the “alien” part: stack variables living on once the creator has returned. That’s just such a weird concept to some people, and people who are used to using closures don’t quite see that, I think.
Later, I decided to do something rather scary. I’ve hidden it after the jump.
These days, we’ve seen something quite remarkable: Superhero movies that are actually good. Or better, I suppose. It’s not as if a high bar has been set.
With these movies appearing, there has been, of course, a sudden interest in the associated comics. However, it can be kind of difficult to figure out what you should read, if you’re interested in checking out some of these stories.
Also, in some cases, it’s pretty much impossible to read them, or you’d probably be overwhelmed by the utter Silver Age cheesiness. Or perhaps not impossible to read. More like impossible to read with a straight face.
With that having been said…
Let’s talk about comics. Specifically, let’s talk about comics relating to some recent movies. We’ll just consider this a reading list; it may be updated from time to time. My expertise is Marvel comics, for the most part, so that’s what will be focused on here. There will be a few notes here and there indicating what you can expect to get out of reading the stories. I’ll also focus on getting the stories out of the “Marvel Essentials” series, since they’re a cheap way of getting a whole bundle of old comics.
And some recommended reading:
Wow, uh, it has been a month. I have been terrible at this, even though I was sure I’d be able to write at least one of these posts a week.
All righty then, no time for self-loathing.
A couple of weeks ago, I traveled up Virginia-wards to visit my friend Jen and check out the capital of our nation, Washington, D.C. Specifically, the intent was to check out as much of the Smithsonian one can check out in a day, and hit all the major monuments.
We checked out the Smithsonian Castle, the Air and Space Museum, the Natural History Museum, and the National Museum of the American Indian. As a note, the Smithsonian Castle doesn’t have a whole lot; it’s really just sort of a jumping off point. The thing I wanted to see there was the Smithson Crypt, because, admittedly, I saw it on Mysteries at the Museum on the Travel Channel.
That’s also how I found out about the Tellus Science Museum in Cartersville, GA, but that’s neither here nor there.
Anyway. All good stuff! Seeing those museums was kind of a childhood dream for me. Same with seeing the monuments; we did a little walking tour, starting with the Lincoln Memorial and ending with the Jefferson Memorial. It’s rather imposing and humbling seeing these in real life, since generally you only ever see them in books.
DC is interesting. For example, since it is our administrative center, there are very few places you can go to eat there, as most of the buildings are what you’d expect: the places where the sausage is made, so to speak. It also doesn’t feel…right. I’m not sure how to explain it. I guess because I’m not used to being anywhere that’s planned. Or something. It’s just a weird feeling.
So last week, I was in Karlsruhe, Germany for the International Conference on Robotics and Automation (ICRA), one of the Big Two in terms of robotics conferences. (The other one is IROS.)
I was a coauthor on a paper, and one of my labmates and I participated in a robotics competition involving DARwIn-OP, a fun little humanoid. We also won the competition! Prizes included another DARwIn, a LabView license, and a Webots license. It was a really good night that night. Robotis held a celebration banquet of sorts at one of the local places to eat, and then we also went to the conference banquet for dessert.
Oh, and there were also interesting talks and lots of other robots, and and and let’s just say I was pretty glad that I went to ICRA.
Now, Germany.
There are a few things I probably won’t ever get about the country, and that’s okay. Such as:
Of course, there are also awesome things:
One of the best things of all was the trip to Triberg, in the Schwarzwald (Black Forest). The main purpose of the trip there was to obtain a cuckoo clock for my mother, since the Black Forest is where cuckoo clocks come from. Side trips included the waterfall, and just wandering around and looking.
The place is absolutely beautiful this time of year. Probably one of the most beautiful places I’ve ever visited. Man, so awesome.
So yeah, southern Germany just before summer, I highly recommend it.
It turns out that in Words With Friends, if you play the word LOVE on a triple word score, you get 42 points.
There are layers here I cannot begin to peel. A veritable onion.
Years ago, I was an active member of the MUSH/MUX community. To put it simply, I was part of several online text-based games that put more of a focus on the roleplay aspect than the hitting things aspect.
However, talk came back around to the hitting things aspect from time to time. Specifically, a set of mechanics built into a game that allowed two players to enter combat with each other with some impartial referee deciding on the outcome, rather than the players having to discuss how events were to turn out.
To do this, you needed a combat system.
Combat systems are fairly complicated things compared to most systems built into a MU*: barring well-known bulletin board and weather systems, which most people just download and use rather than coding themselves. Most people don’t even bother releasing their code if they made one.
I recently gave this some thought (i.e., inspiration struck in the shower), and I’ve come up with a list of requirements that you should consider if you want to develop a combat system for one of these games. Some of these requirements would not be simple to implement, but that is the nature of the beast. Also note that this is nowhere near a complete list.
The requirements are as follows:
This list of requirements raises a few questions. One of the primary questions is “What does it mean to grow in level?” Mostly, since in these types of games, you are likely not going to have wandering monsters that you can take out for phat expees and lootzzzz, as they say. One way of implementing such a requirement is to allow level to be based on logins and character age. For example, each login earns a static amount of experience based on the number of logins and the number of months (years, etc.) the character has existed.
Additionally, what does it mean to choose a class? What are the associated abilities? Do they have cooldown timers? Do you want your characters to have statistics such as strength, wisdom, and charisma, and do you want those statistics to figure into damage? What does it mean to damage something?
…As you can see, it becomes a rat’s nest very quickly. But, a small list of requirements to help you get started better than flailing around wondering what you should do at all.
I’m writing this up as a note as much for myself as it is for the edification of others. Since nobody seems to clearly explain how to go about doing this in Matlab.
Okay, so you want to make a heatmap plot of something in Matlab. What is that exactly? Well, let’s just say you have a 2-d Gaussian mixture model (GMM) and you want to plot all possible values of its likelihood function. You might end up with something like this:
(Ignore everything except the GMM; this is sample stuff from a paper I’m working on.)
Here’s how you do it, step by step, but slightly truncated at certain steps:
meshgrid(). E.g., [X Y] = meshgrid(-100:1:100, -100:1:100);size() of X, generate a matrix of zeros: M = zeros(size(X)); (You can use the size of Y as well, since they should have equal dimensions.)[X(i,j), Y(i,j)]' with i = 1 to the number of rows of X and j = 1 to the number of columns of X; for example: M(i,j) = p([X(i,j); Y(i,j)]');.image() function to draw your heatmap. Use the following command to do it correctly, given the example parameters above: image([-100 100], [-100 100], M, 'CDataMapping', 'scaled');Note that this process can take quite some time depending on how many points you generate using meshgrid(). If you want high resolution heatmaps, though, you’re going to have to generate a lot of points. If you’re able to vectorize or otherwise accelerate the function evaluation process, by all means do so, as that’s where the bulk of your time will be spent.
So in our previous episodes, we talked about some of the issues and ways we can make a robot move.
How does this even apply to a real robot?
In many small robot applications, we like to use robots with two wheels that are controlled separately. This is referred to as differential drive or differential steering. Robots that behave like cars (i.e., four wheels, with two dedicated to steering), operate under the principles of Ackermann steering. It’s a little more complex, which is why we, as I said, like to use robots with two wheels.
You can read all about the geometry behind differential drive, but what we’re interested in is just how to make our robot move.
So, from before, recall that we have two parameters: the linear velocity v and the angular velocity ω. Usually, for most wheeled robots, we can only move in discrete units, depending on a value that is set in some register. We will refer to this value as Cw.
(Note: You will likely have to figure out the value of Cw empirically. It will also likely be different among robots of the same model, due to motor nonlinearities, so, in this case, your mileage may truly vary.)
The basic differential drive equations can then be written as follows:
Where Nr is the number of units for the right wheel, Nl is the number of units for the left wheel, and d is the distance between the centers of each of the wheels.
The two quantities for the number of units are what we need to drive the robot. So, with some algebra that I’ve done for you, it’s easy enough to figure out how we need to set those values to get the robot to do what we want:
Plug those into your code, and you’ll be able to get your robot going at any speed you like. Just keep in mind that often you may be able to set these values as low as 1, but this will not cause actual movement in the robot. So be aware that the minimum speed you calculate will likely not be the minimum speed you can actually go.
And that’s it for this short little series on basic robot movement. Hopefully you learned something interesting along the way!