Nothing super interesting to write about last week.

Mostly just a lot of moving around data to support adding new screens into the game. Specifically a screen for inventory management and a screen to view Red’s status. The data storage needed to be relocated because opening a new screen requires that the game drawing thread be terminated, and since the game state data is stored in the game drawing thread, that would be terminated along with it.

To prevent this, I needed to decide whether to write all game state data into the save file, like you were quitting the game, or remove the data from the game drawing thread, then fix everything that breaks as a result. Saving the data to a file takes too much time and resources when we want to seamlessly switch to a new screen, so I went for the latter option.

Some other updates include:

• Projectile weapon charge tracking for the three types of projectile weapons mentioned in the post for Day 16.
• Player menu is dynamic based on whether or not you’re on stairs (to ascend and descend) or if you have a projectile availabile.
• Saved game versioning, so when I make an update the game doesn’t crash when I try to load an old version of the save file.
• Added inventory items into the save and load game routines.

Today and this weekend I’ll be writing up a random dungeon generator. Perhaps I’ll even have a full day to work on it between now and when I finish. I think I’m going to cut out some extra-curricular activities next week so I can put some solid blocks of time into the game. Chipping away at my todo list for only an hour every day isn’t cutting it anymore.

Current demo:

Red can change gear, drink potions, and read scrolls. Gear includes weapon slots for projectile and melee weapons, an armor slot that reduces damage, and two ring slots which can give various effects.

I’ve already been seeing a bit of slowdown in my game, and I have a hunch it’s because of the way I set up my core state machine and timer. But that’s not what I want to write about today. Today we’re going to use Dijkstra’s Algorithm to make our monsters smarter.

Dijkstra’s Algorithm takes points connected by lines with weights and tries to find the path between two points with the least combined weight of the connecting lines. This is trivial if there’s only one path from A to B, but not so much if there’s multiple routes. The algorithm goes something like this:

1. Start with all points’ values to infinity and not-final.
2. Set your starting point to zero and remember it as current.
3. For each point connected to current:
4. -If that point’s value is not-final, ignore it.
5. -If the point’s value is less than current’s value plus the weight of the line connecting, ignore it.
6. -Otherwise set the point’s value equal to current plus the weight of the line.
7. Mark current as finalized.
8. Pick a non-finalized point connected to current and repeat steps 3-8 until there are no more non-finalized points in the graph.

Now each point’s value is the shortest possible combined weight of the path to the starting point. To find exactly which lines to travel, just traverse backward through the lowest-valued points until you reach the destination. Easy!

The point-line paradigm can be easily applied our game map: the points are map tiles, with a line to each of the tiles surrounding it. If we mark the player’s location as the starting point and each line has 1 weight, we can determine the number of steps required to hit each map tile, and the optimum path for each tile to get back to the player. So now if we have a monster on any tile, we can chase the player around corners; instead of having the monster blocked by a wall while trying to go north-west, it can go north to get around the wall. The monster can also seek out higher valued tiles if he wants to run away from the player.

I tried three approaches to write this algorithm for the game. The first attempt was an elegant recursive algorithm, which threw a Stack Overflow error after traversing 250 lines. Next attempt worked successfully, but took about a full second to calculate each tile – much too long. After some tweaks, I had it down to 1/20th of a second. Much better.

Aside from that, I did end up rewriting the core state machine to make the game very noticeably faster. And a few more things since day 10:

• Haste status effect: you make two moves for every one enemy move.
• Slow status effect: enemies make two moves for every one of your moves.
• New slime enemy that uses the slow effect.
• Optimized how projectiles are handled.
• Fixed nasty bug when when monsters and projectiles are destroyed.
• Moved all strings into resources so they can be easily translated in the future.

Current demo: Game runs at double the previous speed, and enemies follow you without getting stuck on walls. There’s a new type of enemy that keeps slowing you until you kill it.

I’ve been thought-dumping on facebook lately. Take a gander! Old posts are hidden to non-friends but I think everyone who reads this is on my facebook list. Newer posts are open to the public.

I was discussing computery things with the coolest Coloradoan chick I know, and I was reminded of an old football game I wrote for the TI-89 graphing calculator in high school. Here’s a link. Apparently it was pretty popular – it’s gotten nearly 10,000 downloads from the site.

I started it on a car trip to North Carolina for a family Christmas trip and continued working on it for a couple months afterward. Reading the documentation brings a tear of nostalgia to my eye. Especially the thank yous, wherein I thank RHCP for their kick-ass programming music. I had great taste in music back then, didn’t I?

If you have any bugs to report, questions, suggestions, or you just
want to say 'good job' or 'this game sucks', you can email me at
jester323@ignmail.com.

I was tossing my freshly washed clothes into the dryer yesterday and I noticed a peculiar setting for the automatic dryness sensor: OPTIMUM DRY. I’ve always kept the dryer at this setting, but I never pondered the terminology. Really, anything other than optimal dryness would be sub-optimal. Who wants anything suboptimal when optimal is an option? In my mind, the other options might as well be still wet and burnt to a crisp. Claiming to be optimum is quite a tall order, but my dryer delivers; I’ve never pulled a moist or charred piece of clothing out. The only way my dryer could be more optimum is by folding the clothes when it’s done. When that happens, I’m gonna start buying guns, ’cause there’s some Terminator shit goin’ down.

Along with Optimum, there’s More Dry, Less Dry and Fluff. There’s also timed-dry for when you’re on some kind of laundry-time budget. Those settings are for laundry noobs. Give me Optimum or give me a new dryer, I’ve always said! Actually, this is the first time I said it, but I’ll probably say it again soon.

I’m still searching for a stove/oven with an optimum deliciousness setting.

Jim: i haven’t gone grocery shopping in awhile
Jim: my grandma sent some catfood for Valentine’s Day
Jim: and I’m hungry
Jim: do the math, and you will arrive at what I’m seriously doing right now
Me: grocery shopping?
Jim: no

Fortunately, his grandma feeds her cat tuna.

I did. Just today.

When I hung up the phone, I felt liberated. A weight has been lifted from my shoulders to the tune of a grand per year. I can’t believe I’ve been paying that much for something I use so little.

I’ve been watching most of my TV through Hulu and Torrents lately, so this shouldn’t affect my day-to-day too awfully much. I like to fall asleep to Discovery or Conan, but I think I can learn how to use my clock radio for that.

Hmm, what else can I find that I don’t use often? Anybody want to buy a Wii?

Here’s a haiku to apologize for the lack of activity recently.

I love this snow verily
I drive through it so merrily
It shouldn’t be distributed so sparingly

Ok, so it’s not a haiku, I don’t care. Have a happy Christmas and a merry New Year!

AC/DC is the most energetic live show I’ve ever heard of.

Here’s some pictures of the show.

Yesterday was a significant day in an industry that defined my childhood and inspired me to be what I am today. The original Sega Genesis turned 20.

October 29, 1988 – The Sega Mega Drive was released in Japan to a relatively unimpressed crowd. NEC’s PC Engine had already been released and had gained significant headway in the market. Sega’s 16-bit system couldn’t close the gap, especially after Nintendo’s Super Famicom showed up on the scene.

January 9, 1989 – Sega re-branded and released its system as the Genesis in the United States. It was the first 16-bit system to be released in the US and gained a decent market, advertising its vague “Blast Processing” as a key feature in the system. In 1991, Nintendo released the Super NES, which, like in Japan, came out ahead in the console wars, due to its dominance in the 8-bit market.

Spring 1994 – We received a hand-me-down Genesis with a few games from my grandpa. As the first real game system I owned, this donation fertilized the seedling that would become my obsession with video games. That opened my interest in how the games were made, which naturally lead me to making my own games with anything that was programmable: BASIC on our computer, TI Calculators, final projects in classes, etc. Over time my drive to make games has waned, but my obsession with them has not.

Happy B-Day, Sega Genesis. Sonic 3 & Knuckles will forever remain my favorite stackable game featuring an animal whose species name I still can’t pronounce to this day.