See if you can spot Brendan in this one. I'll give you a hint: he has the craziest hair. Plus, he says his name. I also laugh when they subtitle Brendan's Japanese in katakana, doing nothing to dispel the widely-held belief in Japan that foreigners are remedial and can't speak the language. Mostly true, but still...
Back in "the day," as the kids say, I actually had to make "real" programs for "school." The programs were half-arsed, but I call them "real" because they were written in a compiled language, using a relatively modern graphics API, OpenGL. I was taking a class on computer graphics, and the professor used OpenGL as a teaching tool. It wasn't very effective, namely because he was a crap lecturer. Every class, all he did was go through the mathematical equations used to produce various graphical effects. I'm sure it was all useful information, but it wasn't very interesting, and I have forgotten all of it. He didn't teach anything about using OpenGL to make stuff that actually looked good, which was what I was hoping to learn when I signed up for the class.
In the end, the only redeeming factor of the class were its assignments. There's not much I love more than being given some outlandish goal and told "do it." The first assignment was definitely that... creating a paint program with a GUI, all without any prior knowledge of graphical programming. I learned a ton about mouse input and how the Cartesian coordinate system was my best friend.
The final assignment in the class was open-ended. Each student was supposed to get in a group and create a program that displayed all the knowledge you'd acquired during the semester. Since my friend Sam and I spent most of our summer vacations during high school playing Mario Kart 64 and Bomberman 64 for eight hours a day, we decided to make a videogame. Our inspiration came from searching through old arcade ROMs on a MAME installation: Camel Try. Camel Try was a game in which the player tried to lead a small marble through a maze in a limited time. Instead of moving the marble, however, the player rotated the maze around the marble, while the marble itself fell downwards constantly. It was a pretty fun game; the idea of the rotating maze made such a simple concept (find the exit) much more compelling.
At first glance, this type of gameplay might have seemed too complicated for a beginning programmer, but some of the few things I had learned in my class were OpenGL functions that allowed for easy rotation of objects on the screen. This gave me confidence to embark on what was otherwise a fairly complex project. I had a brief moment of happiness when, in one of my first game builds, I saw the rudimentary collision detection system work correctly.
In the end, my friend Sam (who was my partner in this venture) and I got a pretty bad grade for the project. We had spent too much time on the physics and control of the game, rather than its' looks. As a first step in game development, the program was pretty good; as a showcase for OpenGL features, not so much.
What I call "the marble genre" is fairly pervasive, however. I used it as a first step into game development; others polish up the idea and try to hock it commercially. Kororinpa: Marble Mania for the Nintendo Wii is one such title. The basic idea of Kororinpa is the same as my game: navigate a marble through some sort of obstacle course. However, a number of details are different. Instead of using buttons or an arcade dial to move the maze, the Wii remote controls the orientation of the game world. Tilt the remote upside down, and the maze follows suit. It's actually very reminiscent of the old wooden "Labyrinth" marble games. Collect all the red crystals within each level to activate the exit, and move onto the next area.
And that's the entire premise behind Kororinpa. Really, all that's left to discuss is production values. The music, art, and design are all very well done. Every ten levels or so, the theme behind each maze changes; from "Forest" to "Candyland" to "City." The difficulty of each level also slowly increases. Collecting hard-to-get green crystals unlocks extra content, such as additional music and marbles. Each different marble has defining characteristics, such as erratic movement, annoying noises, or increased/decreased speed. To tell the truth, if I could affix any adjective to Kororinpa, it would probably be "polished."
The problem is, though, that for all the polish, the control is just a bit too wonky. The level has a predisposition to be tilted towards the player, which is the easiest motion to make with the remote. Tilting away puts strain on the wrist, and doesn't happen as quickly or dramatically as one would like. It's almost easier to hold the remote like a dart, rather than in the traditional way. If the control problems could be solved by holding the remote differently, that would be fine, but unfortunately the marble movement is also overly sensitive. I had to exercise undue caution, or else my marble would plummet off the edge of the level.
If Kororinpa was compelling in any other way aside from its' high production values, no doubt I would have persevered in playing through it. As it was, however, I didn't feel the frustration in control was worth the continued playtime... a problem I seem to face all too often.
Still working on the new theme/layout, but thought I'd post some junk here befitting the new header graphic.
Derek Yu interviews Pixel, the creator of Cave Story.
Visited Play-Asia.com, and was taken in by their weekly special: a Japanese copy of Meteos for $15. Next thing I knew, I was also grabbing Guilty Gear XX: Accent Core — another long-awaited game. Meteos is a DS puzzle game produced by Tetsuya Mizuguchi, of Lumines fame. I really don't know much else about it, except that it's supposed to be good. Lumines was pretty awesome, so I don't feel like I'm taking too big of a risk here. I've wanted a copy of Guilty Gear for a darn long time; I bought Isuka in Japan, but it's not very fun. There's a reason why 2D fighting games are mainly for two players.
CakePHP has all sorts of nifty form helpers that I would ordinarily never use, except for the fact that they get put in the auto-generated views. The helper that creates a day/month/year select tag automatically lists years from like 1947-2017... way too many. I normally don't care, but a client complained about it this morning, so I had to go searching around for a way to fix it. Rather than go into the code itself, I prefer to be lazy and just search the net to see if anyone else has written something about it. Jackpot! Some dude has written how to modify the dateTimeOptionTag().
In case that page goes blank, the gist is editing
/cake/libs/view/helpers/html.php, which is the HTML Helper. Find the calls to yearOptionTag(), and change the third and fourth parameters to your start and end year, respectively. I used date("Y") and date("Y", strtotime("+4 years")).
[Edit] Alternately, just modify yearOptionTag() itself... the place to change the code is pretty obvious.