Charity Game Jam : Gasoline Roulette

The game in ye old'e Funkytron

Made for Ludum Dare's 48 Hour Charity Game Jam.  The game itself is really awful, but you can play it in the Funkytron alongside all the other games that put mine to shame.

Mediafire Download

First time making a game in HTML5 though, and I'm really liking it.  Took about five hours without having learned any of it beforehand (aside from basic Javascript).  Uses LimeJS.

The original idea involved both players drinking a tank of gasoline, and then proceeding to fly into overly-dramatic Mortal Kombat poses while cutting off their own limbs, lighting them on fire, and using them as molotovs to chuck at the enemy player.

And then I remembered this charity was for Make-A-Wish, and that might not bode well with pretty much anyone.

The nice thing about HTML5 is that it's instantly iOS and Android compatible, and I could take this game to market immediately if I wanted to.  It's certainly a lot less painful than coding it up in Java or Objective-C.

C++ : Sketcher - Oversegmentation

The original image ("MAIN IMAGE") is convoluted with a 3x3 Sobel filter to produce ("CONVOLVED IMAGE"), which is supposed to accentuate edges but it clearly isn't working.  The image is then lazily tacked with a thresholding value to produce individual "islands" of color ("BLOB IMAGE").

Tomorrow will be non-maximum suppression day and then hopefully it won't look so pitiful.

Be Nice To Programmers?

Stumbled upon this (or, rather, was shown it).  Read that before you continue.  Here's my take on it:

The difference between programming and, say, sports, is that programming tends to be an all or nothing plan.  You can't build half an algorithm and get half the satisfaction out of it; half an algorithm is, essentially, a broken algorithm.  Zero points.  And when you're dealing with programming, nine out of ten times, your algorithm will be broken.

The positive feedback only comes upon finishing the program, and then it has to be absolutely perfect.

Let me explain from my point of view.  If you've followed this blog at all, you'll know I do a ton of time-crunching game jams.  Imagine this: It's the last hour in what was just a 72 hour jam, where you sacrificed life and limb to finish your game.  You finally submit it within the last few minutes, breathe a sigh of relief, and go test it.

There's a game-breaking bug after the first level.

All of the feedback you get is generally positive, because the indie game community is generally awesome and supportive, but all you can think of is if I had not typed that one variable wrong I would've had a functional game.

The problem is even worse in the work force, because due to the flexibility of digital media/software in general, clients work closely with their programmers to make it worth the project cost.  Hence, every flaw is pointed out.  If the program is not 100% perfect then it's not worth their money.

Now, the absolute worst is when you're working for a large company.

On really large projects, administration tends to partition individual pieces of the issue to different programmers, so that your own job is fairly manageable.  However, it also means that your own job is fairly insignificant.  Imagine being the guy that optimizes shaders in Halo.  There really is no positive feedback, at all.  After slaving on pushing assembly code around for months, once the game's released, you can play it and say, "You see how the light refracts off of mossy rocks?  I made that twice as fast."

Not very satisfying.

Now, here's where I disagree with the original link.  I mentioned that nine times out of ten, your efforts result in absolute failure.  But that other ten percent is the greatest feeling in the world, when you've slaved a week, or two weeks, or even a few hours on a program, and it comes to life and it's brilliant, it's all really worth it.

C++ : Sketcher - Part One

New project!

"Given an image, design a program to draw out the image in sketch form similar to how a human would."

Workflow:

1. Split "superpixels" of the image through edge detection and pattern recognition.
2. Guess the subject of the image by finding the area with the highest density of "superpixels."
3. Use machine learning techniques to sketch the image.

Split "superpixels" of the image through edge detection and pattern recognition.

Saxena, Sun, and Ng offers a super-basic rundown of this.  A guy from the IRC had the idea of running the pattern recognition engine alongside the first derivatives of the images instead of the raw image (via Prewitt or I guess perhaps Sobel too).

Imagine finding patterns in, i.e., a black/white checkerboard.  It'd be easier to detect the square pattern through an edge-detector (Roberts, Prewitt, Sobel) since you'd end with a grid of squares, with no distinguishing black or white, while with the raw image you'd have to convince your program that the color of the square is irrelevant.  Same goes for pattern recognition in a field of grass; the important factor isn't the color of the grass, it's the texture - the repetition of grass-shadow-grass-shadow all along the field.

I'm confident this part won't be too much of a problem.  That being said, I'll probably fail here anyways.

Guess the subject of the image by finding the area with the highest density of "superpixels."

The idea behind this is that areas with low density are either blurred (due to camera focus) or background (sky, etc.), and it'll all be grouped into one superpixel via Step 1.  Now, actually sifting the image for highest densities will be a pain.

The most straightforward way is to just split the image into arbitrary squares (say, 64x64) and the square with the highest number of superpixels wins.  Then, process smaller squares in the same fashion within the candidate square, until some threshold or another.  But this suffers from the fault that there's no stopping the subject from being split in half by the grid.  In fact, it's almost certain to happen.

Probably some way to do this via an undirected graph.

Use machine learning techniques to sketch the image.

Supervised learning and neural networks.  Other than that, no fcking clue.

...It'd be really nice to not have college apps/school.  That way I'd actually be able to work on this.

VESPER.5 : The Journey

Alas, I have accepted the trials and tribulations of VESPER.5 .  Let's see how long I last.

The game is simple; move once every day.

The experiment is just as simple.  Ever wonder why people play MMORPGs so religiously?  Or why a game feels so much more meaningful when it's 40+ hours long?

There's only one real, reliable way to make players feel awful, and that's making them lose something.  Maybe you can only play the game once.  Maybe the game deletes a random file on your computer every time you get hit.  Or, maybe, make the game so impossibly long that any slip-up leading to death will cause the player to rage and cry.  (Read: roguelikes).

VESPER.5 does the latter.  The game itself is unimpressive.  All of the meaning is derived from one fact alone; you cannot move more than once per day.  Every day, you log on, knowing you have to be careful, taking deliberation over your course, but at the same time, it's zen.  A direct counter to the fast-paced, do-everything world of games and reality itself.

I've made my one move today.  Challenge accepted.

4 Hour Jam Revival

4 Hour Jam

Edit: Jam #4 a success!  Post-Mortem

Make an (anything) in 4 hours!

It's an extremely informal jam for developers of any kind.  Graphics artists, composers, storyboard writers, etc.

Come join us on the IRC!  November 10, 2 PM - 6 PM EST.

Thanks to CaptainLepidus for spawning the revivalist movement and everyone else for being fantastic people and making this happen again.

Edit:
Abandonware has also volunteered to host a Minecraft server alongside the jam.  See his post for details!

Statistically speaking, your vote really doesn't matter

Now, I'm not going to discourage you from voting.  As long as you have an ounce of knowledge that comes from credible sources, it's in the advantage of the country for you to vote (and if you're voting based on campaign ads / what your friends are voting, SHAME ON YOU).

Statistically speaking, the chance that your vote will change the election is slim-to-nothing.  XKCD provides a nice run-down of the probabilities.  Knowing this, why do so many people vote?

The power in voting comes from the illusion that your vote matters.  If voter apathy prevents one person from voting, then there's virtually no harm done.

The damage happens when a large group of people suddenly decide (logically so) that the gas it takes to drive to the voting place and the hours of time wasted at the voting booth isn't worth the minuscule chance that their vote will be a determining factor.  It's then where you'll have some problems.  One vote will not make a difference, but ten thousand votes certainly will.

So the next time the election rolls around and people try to guilt you into voting, remember this: It's okay not to vote.  Just as long as you encourage everyone around you to vote.

And just as long as not too many people read this blog post.