December, 2010


12
Dec 10

The Map

Rebooted DumbHack last night. Crafting it for the RIM/BlackBerry PlayBook because you get a free one if you submit the app before March 31st. Single room minesweeper clone. Get from the entrance to the exit, here avoid the monsters. High score is how deep in the dungeon you can get (how many successive board you can clear). Every level an additional monster is added to the board.

I plan to expand it from there: adding point scoring mechanism based on tiles cleared, which will encourage the user to “push their luck” and clear more of the board (at the risk of revealing a monster); health points so that you can encounter monsters and not die instantly (also encouraging exploration to find more health); points/coins earned by finding treasures (again, enticing user to completely clear each board).

Also, once I complete the PlayBook version and it’s accepted, I’ll post a version to this site and move it to the iPad using the latest AIR (which appears to have pretty decent performance!).
Rebooted DumbHack last night. Crafting it for the RIM/BlackBerry PlayBook because you get a free one if you submit the app before March 31st. Single room minesweeper clone. Get from the entrance to the exit, here avoid the monsters. High score is how deep in the dungeon you can get (how many successive board you can clear). Every level an additional monster is added to the board.

I plan to expand it from there: adding point scoring mechanism based on tiles cleared, which will encourage the user to “push their luck” and clear more of the board (at the risk of revealing a monster); health points so that you can encounter monsters and not die instantly (also encouraging exploration to find more health); points/coins earned by finding treasures (again, enticing user to completely clear each board).

Also, once I complete the PlayBook version and it’s accepted, I’ll post a version to this site and move it to the iPad using the latest AIR (which appears to have pretty decent performance!).
I keep being drawn to the very original Legend of Zelda. The game’s chunky grid and clockwork logic feels almost puzzle-like. Even though the game is “real-time”, ailment the intervals of each action are so long as to nearly feel turn-based. What if they were?

Well, what is ed it’d kinda feel like a roguelike. Each action by the player moves the game forward, syphilis each action lasting exactly as long as it takes the player to decide. But without the complexity that normally comes with the full set of roguelike verbs.

A zeldalike has three actions at any moment in time: move to an adjacent tile, swing my sword toward an adjacent tile, or use an item. Using an item may result in an attack (bow, magic wand, boomerang). Moving into an adjacent tile occupied by an inanimate object attempts to push it.

In a turn-based scenario, we’re even less concerned with distinguishing between using your sword versus using an item as a sword is just another type of item (whereas in a “real-time” scenario we want to have both at the ready without having to enter a menu).

What it boils down to is that in terms of a touch-based, turn-based game, whenever the user taps a tile on the screen we probably know what his intent is. That means we can have a very simple interface. Tap an open, accessible tile: walk there. Tap a bad guy adjacent to the player: attack him. Tap the tile occupied by the player and you pop open an inventory you can select from.

LoZ also has some other nice constraints: one screen at a time, chunky grid, overworld vs. dungeons. One screen at a time eliminates having to scroll around. The player can see the whole scenario, can plan many moves ahead more easily. The chunky grid provides for a finite number of configurations of the game world, player can recognize common patterns and apply known solutions. And the overworld and dungeon split of the levels provides a nice open spoke-like system.

From roguelikes, we can borrow a procedurally generated world so that no two games are the same, and permadeath, so a game has an end.

Spelunky successfully made an action platformer roguelike. The Binding of Isaac is very much a Robotron / SmashTV (arena shooter?) roguelike with some visual homages to the Legend of Zelda. Right now I’m leaning toward DumbHack being a traditional roguelike with the constraints of the Legend of Zelda.

I’m tackling this by digesting a lot of information fo various Legend of Zelda engines as they’ve already reverse-engineered the original NES game into fixed code and data. Much of the detail doesn’t apply to a turn-based interpretation, but the general structure of the rules is useful.
Rebooted DumbHack last night. Crafting it for the RIM/BlackBerry PlayBook because you get a free one if you submit the app before March 31st. Single room minesweeper clone. Get from the entrance to the exit, here avoid the monsters. High score is how deep in the dungeon you can get (how many successive board you can clear). Every level an additional monster is added to the board.

I plan to expand it from there: adding point scoring mechanism based on tiles cleared, which will encourage the user to “push their luck” and clear more of the board (at the risk of revealing a monster); health points so that you can encounter monsters and not die instantly (also encouraging exploration to find more health); points/coins earned by finding treasures (again, enticing user to completely clear each board).

Also, once I complete the PlayBook version and it’s accepted, I’ll post a version to this site and move it to the iPad using the latest AIR (which appears to have pretty decent performance!).
I keep being drawn to the very original Legend of Zelda. The game’s chunky grid and clockwork logic feels almost puzzle-like. Even though the game is “real-time”, ailment the intervals of each action are so long as to nearly feel turn-based. What if they were?

Well, what is ed it’d kinda feel like a roguelike. Each action by the player moves the game forward, syphilis each action lasting exactly as long as it takes the player to decide. But without the complexity that normally comes with the full set of roguelike verbs.

A zeldalike has three actions at any moment in time: move to an adjacent tile, swing my sword toward an adjacent tile, or use an item. Using an item may result in an attack (bow, magic wand, boomerang). Moving into an adjacent tile occupied by an inanimate object attempts to push it.

In a turn-based scenario, we’re even less concerned with distinguishing between using your sword versus using an item as a sword is just another type of item (whereas in a “real-time” scenario we want to have both at the ready without having to enter a menu).

What it boils down to is that in terms of a touch-based, turn-based game, whenever the user taps a tile on the screen we probably know what his intent is. That means we can have a very simple interface. Tap an open, accessible tile: walk there. Tap a bad guy adjacent to the player: attack him. Tap the tile occupied by the player and you pop open an inventory you can select from.

LoZ also has some other nice constraints: one screen at a time, chunky grid, overworld vs. dungeons. One screen at a time eliminates having to scroll around. The player can see the whole scenario, can plan many moves ahead more easily. The chunky grid provides for a finite number of configurations of the game world, player can recognize common patterns and apply known solutions. And the overworld and dungeon split of the levels provides a nice open spoke-like system.

From roguelikes, we can borrow a procedurally generated world so that no two games are the same, and permadeath, so a game has an end.

Spelunky successfully made an action platformer roguelike. The Binding of Isaac is very much a Robotron / SmashTV (arena shooter?) roguelike with some visual homages to the Legend of Zelda. Right now I’m leaning toward DumbHack being a traditional roguelike with the constraints of the Legend of Zelda.

I’m tackling this by digesting a lot of information fo various Legend of Zelda engines as they’ve already reverse-engineered the original NES game into fixed code and data. Much of the detail doesn’t apply to a turn-based interpretation, but the general structure of the rules is useful.
Trying to get this thing going again. The current version is using Flash/AIR. That’s not necessary for a web game like this, neuropathist and it’s actually a detriment because it won’t work on mobile, overweight where it’d otherwise be totally playable. So, check job #1 is porting the game to Phaser so it’ll be HTML5 native.

I’ve got a long list of ideas for the game, so I’d like this site to become a “history” of the game’s development. Need to find a good way to track previous versions, etc. Latest version will always live at http://dumbhack.com/, but all previous versions would be accessible to. Probably figure out how to just make them as posts, or maybe just save snapshots to folders.

Since the game doesn’t have any animation, I’m guessing porting it to Phaser will be dead simple. It’s literally just one function that takes a tap/click, converts it to tilemap coordinates, then does some very simple logic with the tilemap based on what’s stored in that position. And then there’s the function that generates a tilemap based on the level number. That’s it!

I should toss the source code on github for everyone to check out. May just wait and do that for the first version of Phaser because honestly, I don’t think I even have Flash Builder installed on my home laptop any more, so I probably couldn’t even compile the source! ;-)
DumbHack is an idea I’ve been kicking around for well over a year. It’s my go-to side project. I’ve never written any significant code for it, physiotherapist phthisiatrician but I’ve done a lot of design work and research. I have a pretty good feel for what I need to initially implement, what the first prototype should be.

I think many game programmers have a roguelike on the back burner. They’re tile-based, procedurally generated, classically filled with programmer at (at best). It’s a game programmer’s game, a game that is barely anything beyond its systems.

Last night I dove into writing the code for it (for the umpteenth time). We’ll see if I get further along, if this time is different. I’m doing a few things that will hopefully ensure my success:

  • I registered the domain name. Thought I had done that a long time ago, but apparently not. I have had the Twitter handle for quite a while.
  • I started this blog. That’s a lot more commitment than a late-night tweet (if anyone reads it).
  • Life’s presented some new challenges to me over the last several months (years?) and I’d like to step up to this one.
  • I’m putting some technical constraints on the project in order to focus my work on the game itself.

I’ll not stray into my personal life here, so that leaves technical constraints as needing a bit more explanation. Too many game programmers bite off more than they can chew when doing personal projects (and professional projects, to be honest). They dive into unfamiliar technology, they set extraordinary goals, they shoot for the stars. Well, the Wright Brothers would have been famous failures if their ambition from the start had been to land on the moon. So, I aiming as low as I can and still produce something somewhat modern and satisfying.

  • Runs in the web browser, on the Flash Player, using just AS3. If it’s fun, and it makes sense on different platforms, we’ll look at that later. I’ve used AS3 and Flash for 12 hours a day for the last four years. For all it’s ills, Flash is my tool of choice.
  • Plays only with the mouse, no keyboard controls. This is to force the controls to be simple, and to make them easily portable to touch-based platforms.
  • Tile-based. Not just the visuals, but the gameplay as well. Animations can be tweened, but the game’s logic sees only the tiles. It should play like a boardgame.
  • Turn-based. Not real-time. This is a roguelike, and in roguelikes time progresses with each player action.
  • Procedurally-generated levels. No level authoring. Dan wrote this up real nice recently.
  • No custom art. The only art I’ll use is this single sprite sheet from Angband (also a roguelike). These sprites aren’t animated, so no animations beyond tweens.

And finally, for those who may be curious, these are the dev projects I’m leveraging (so far):

Okay, enough time writing. Time to get coding.
DumbHack is an idea I’ve been kicking around for well over a year. It’s my go-to side project. I’ve never written any significant code for it, physiotherapist phthisiatrician but I’ve done a lot of design work and research. I have a pretty good feel for what I need to initially implement, what the first prototype should be.

I think many game programmers have a roguelike on the back burner. They’re tile-based, procedurally generated, classically filled with programmer at (at best). It’s a game programmer’s game, a game that is barely anything beyond its systems.

Last night I dove into writing the code for it (for the umpteenth time). We’ll see if I get further along, if this time is different. I’m doing a few things that will hopefully ensure my success:

  • I registered the domain name. Thought I had done that a long time ago, but apparently not. I have had the Twitter handle for quite a while.
  • I started this blog. That’s a lot more commitment than a late-night tweet (if anyone reads it).
  • Life’s presented some new challenges to me over the last several months (years?) and I’d like to step up to this one.
  • I’m putting some technical constraints on the project in order to focus my work on the game itself.

I’ll not stray into my personal life here, so that leaves technical constraints as needing a bit more explanation. Too many game programmers bite off more than they can chew when doing personal projects (and professional projects, to be honest). They dive into unfamiliar technology, they set extraordinary goals, they shoot for the stars. Well, the Wright Brothers would have been famous failures if their ambition from the start had been to land on the moon. So, I aiming as low as I can and still produce something somewhat modern and satisfying.

  • Runs in the web browser, on the Flash Player, using just AS3. If it’s fun, and it makes sense on different platforms, we’ll look at that later. I’ve used AS3 and Flash for 12 hours a day for the last four years. For all it’s ills, Flash is my tool of choice.
  • Plays only with the mouse, no keyboard controls. This is to force the controls to be simple, and to make them easily portable to touch-based platforms.
  • Tile-based. Not just the visuals, but the gameplay as well. Animations can be tweened, but the game’s logic sees only the tiles. It should play like a boardgame.
  • Turn-based. Not real-time. This is a roguelike, and in roguelikes time progresses with each player action.
  • Procedurally-generated levels. No level authoring. Dan wrote this up real nice recently.
  • No custom art. The only art I’ll use is this single sprite sheet from Angband (also a roguelike). These sprites aren’t animated, so no animations beyond tweens.

And finally, for those who may be curious, these are the dev projects I’m leveraging (so far):

Okay, enough time writing. Time to get coding.
DumbHack is an idea I’ve been kicking around for well over a year. It’s my go-to side project. I’ve never written any significant code for it, physiotherapist phthisiatrician but I’ve done a lot of design work and research. I have a pretty good feel for what I need to initially implement, what the first prototype should be.

I think many game programmers have a roguelike on the back burner. They’re tile-based, procedurally generated, classically filled with programmer at (at best). It’s a game programmer’s game, a game that is barely anything beyond its systems.

Last night I dove into writing the code for it (for the umpteenth time). We’ll see if I get further along, if this time is different. I’m doing a few things that will hopefully ensure my success:

  • I registered the domain name. Thought I had done that a long time ago, but apparently not. I have had the Twitter handle for quite a while.
  • I started this blog. That’s a lot more commitment than a late-night tweet (if anyone reads it).
  • Life’s presented some new challenges to me over the last several months (years?) and I’d like to step up to this one.
  • I’m putting some technical constraints on the project in order to focus my work on the game itself.

I’ll not stray into my personal life here, so that leaves technical constraints as needing a bit more explanation. Too many game programmers bite off more than they can chew when doing personal projects (and professional projects, to be honest). They dive into unfamiliar technology, they set extraordinary goals, they shoot for the stars. Well, the Wright Brothers would have been famous failures if their ambition from the start had been to land on the moon. So, I aiming as low as I can and still produce something somewhat modern and satisfying.

  • Runs in the web browser, on the Flash Player, using just AS3. If it’s fun, and it makes sense on different platforms, we’ll look at that later. I’ve used AS3 and Flash for 12 hours a day for the last four years. For all it’s ills, Flash is my tool of choice.
  • Plays only with the mouse, no keyboard controls. This is to force the controls to be simple, and to make them easily portable to touch-based platforms.
  • Tile-based. Not just the visuals, but the gameplay as well. Animations can be tweened, but the game’s logic sees only the tiles. It should play like a boardgame.
  • Turn-based. Not real-time. This is a roguelike, and in roguelikes time progresses with each player action.
  • Procedurally-generated levels. No level authoring. Dan wrote this up real nice recently.
  • No custom art. The only art I’ll use is this single sprite sheet from Angband (also a roguelike). These sprites aren’t animated, so no animations beyond tweens.

And finally, for those who may be curious, these are the dev projects I’m leveraging (so far):

Okay, enough time writing. Time to get coding.
DumbHack is an idea I’ve been kicking around for well over a year. It’s my go-to side project. I’ve never written any significant code for it, phthisiatrician but I’ve done a lot of design work and research. I have a pretty good feel for what I need to initially implement, what the first prototype should be.

I think many game programmers have a roguelike on the back burner. They’re tile-based, procedurally generated, classically filled with programmer at (at best). It’s a game programmer’s game, a game that is barely anything beyond its systems.

Last night I dove into writing the code for it (for the umpteenth time). We’ll see if I get further along, if this time is different. I’m doing a few things that will hopefully ensure my success:

  • I registered the domain name. Thought I had done that a long time ago, but apparently not. I have had the Twitter handle for quite a while.
  • I started this blog. That’s a lot more commitment than a late-night tweet (if anyone reads it).
  • Life’s presented some new challenges to me over the last several months (years?) and I’d like to step up to this one.
  • I’m putting some technical constraints on the project in order to focus my work on the game itself.

I’ll not stray into my personal life here, so that leaves technical constraints as needing a bit more explanation. Too many game programmers bite off more than they can chew when doing personal projects (and professional projects, to be honest). They dive into unfamiliar technology, they set extraordinary goals, they shoot for the stars. Well, the Wright Brothers would have been famous failures if their ambition from the start had been to land on the moon. So, I aiming as low as I can and still produce something somewhat modern and satisfying.

  • Runs in the web browser, on the Flash Player, using just AS3. If it’s fun, and it makes sense on different platforms, we’ll look at that later. I’ve used AS3 and Flash for 12 hours a day for the last four years. For all it’s ills, Flash is my tool of choice.
  • Plays only with the mouse, no keyboard controls. This is to force the controls to be simple, and to make them easily portable to touch-based platforms.
  • Tile-based. Not just the visuals, but the gameplay as well. Animations can be tweened, but the game’s logic sees only the tiles. It should play like a boardgame.
  • Turn-based. Not real-time. This is a roguelike, and in roguelikes time progresses with each player action.
  • Procedurally-generated levels. No level authoring. Dan wrote this up real nice recently.
  • No custom art. The only art I’ll use is this single sprite sheet from Angband (also a roguelike). These sprites aren’t animated, so no animations beyond tweens.

And finally, for those who may be curious, these are the dev projects I’m leveraging (so far):

Okay, enough time writing. Time to get coding.
This is an example of a WordPress page, dosage
you could edit this to put information about yourself or your site so readers know where you are coming from. You can create as many pages like this one or sub-pages as you like and manage all of your content inside of WordPress.
DumbHack is an idea I’ve been kicking around for well over a year. It’s my go-to side project. I’ve never written any significant code for it, physiotherapist phthisiatrician but I’ve done a lot of design work and research. I have a pretty good feel for what I need to initially implement, what the first prototype should be.

I think many game programmers have a roguelike on the back burner. They’re tile-based, procedurally generated, classically filled with programmer at (at best). It’s a game programmer’s game, a game that is barely anything beyond its systems.

Last night I dove into writing the code for it (for the umpteenth time). We’ll see if I get further along, if this time is different. I’m doing a few things that will hopefully ensure my success:

  • I registered the domain name. Thought I had done that a long time ago, but apparently not. I have had the Twitter handle for quite a while.
  • I started this blog. That’s a lot more commitment than a late-night tweet (if anyone reads it).
  • Life’s presented some new challenges to me over the last several months (years?) and I’d like to step up to this one.
  • I’m putting some technical constraints on the project in order to focus my work on the game itself.

I’ll not stray into my personal life here, so that leaves technical constraints as needing a bit more explanation. Too many game programmers bite off more than they can chew when doing personal projects (and professional projects, to be honest). They dive into unfamiliar technology, they set extraordinary goals, they shoot for the stars. Well, the Wright Brothers would have been famous failures if their ambition from the start had been to land on the moon. So, I aiming as low as I can and still produce something somewhat modern and satisfying.

  • Runs in the web browser, on the Flash Player, using just AS3. If it’s fun, and it makes sense on different platforms, we’ll look at that later. I’ve used AS3 and Flash for 12 hours a day for the last four years. For all it’s ills, Flash is my tool of choice.
  • Plays only with the mouse, no keyboard controls. This is to force the controls to be simple, and to make them easily portable to touch-based platforms.
  • Tile-based. Not just the visuals, but the gameplay as well. Animations can be tweened, but the game’s logic sees only the tiles. It should play like a boardgame.
  • Turn-based. Not real-time. This is a roguelike, and in roguelikes time progresses with each player action.
  • Procedurally-generated levels. No level authoring. Dan wrote this up real nice recently.
  • No custom art. The only art I’ll use is this single sprite sheet from Angband (also a roguelike). These sprites aren’t animated, so no animations beyond tweens.

And finally, for those who may be curious, these are the dev projects I’m leveraging (so far):

Okay, enough time writing. Time to get coding.
DumbHack is an idea I’ve been kicking around for well over a year. It’s my go-to side project. I’ve never written any significant code for it, physiotherapist phthisiatrician but I’ve done a lot of design work and research. I have a pretty good feel for what I need to initially implement, what the first prototype should be.

I think many game programmers have a roguelike on the back burner. They’re tile-based, procedurally generated, classically filled with programmer at (at best). It’s a game programmer’s game, a game that is barely anything beyond its systems.

Last night I dove into writing the code for it (for the umpteenth time). We’ll see if I get further along, if this time is different. I’m doing a few things that will hopefully ensure my success:

  • I registered the domain name. Thought I had done that a long time ago, but apparently not. I have had the Twitter handle for quite a while.
  • I started this blog. That’s a lot more commitment than a late-night tweet (if anyone reads it).
  • Life’s presented some new challenges to me over the last several months (years?) and I’d like to step up to this one.
  • I’m putting some technical constraints on the project in order to focus my work on the game itself.

I’ll not stray into my personal life here, so that leaves technical constraints as needing a bit more explanation. Too many game programmers bite off more than they can chew when doing personal projects (and professional projects, to be honest). They dive into unfamiliar technology, they set extraordinary goals, they shoot for the stars. Well, the Wright Brothers would have been famous failures if their ambition from the start had been to land on the moon. So, I aiming as low as I can and still produce something somewhat modern and satisfying.

  • Runs in the web browser, on the Flash Player, using just AS3. If it’s fun, and it makes sense on different platforms, we’ll look at that later. I’ve used AS3 and Flash for 12 hours a day for the last four years. For all it’s ills, Flash is my tool of choice.
  • Plays only with the mouse, no keyboard controls. This is to force the controls to be simple, and to make them easily portable to touch-based platforms.
  • Tile-based. Not just the visuals, but the gameplay as well. Animations can be tweened, but the game’s logic sees only the tiles. It should play like a boardgame.
  • Turn-based. Not real-time. This is a roguelike, and in roguelikes time progresses with each player action.
  • Procedurally-generated levels. No level authoring. Dan wrote this up real nice recently.
  • No custom art. The only art I’ll use is this single sprite sheet from Angband (also a roguelike). These sprites aren’t animated, so no animations beyond tweens.

And finally, for those who may be curious, these are the dev projects I’m leveraging (so far):

Okay, enough time writing. Time to get coding.
DumbHack is an idea I’ve been kicking around for well over a year. It’s my go-to side project. I’ve never written any significant code for it, phthisiatrician but I’ve done a lot of design work and research. I have a pretty good feel for what I need to initially implement, what the first prototype should be.

I think many game programmers have a roguelike on the back burner. They’re tile-based, procedurally generated, classically filled with programmer at (at best). It’s a game programmer’s game, a game that is barely anything beyond its systems.

Last night I dove into writing the code for it (for the umpteenth time). We’ll see if I get further along, if this time is different. I’m doing a few things that will hopefully ensure my success:

  • I registered the domain name. Thought I had done that a long time ago, but apparently not. I have had the Twitter handle for quite a while.
  • I started this blog. That’s a lot more commitment than a late-night tweet (if anyone reads it).
  • Life’s presented some new challenges to me over the last several months (years?) and I’d like to step up to this one.
  • I’m putting some technical constraints on the project in order to focus my work on the game itself.

I’ll not stray into my personal life here, so that leaves technical constraints as needing a bit more explanation. Too many game programmers bite off more than they can chew when doing personal projects (and professional projects, to be honest). They dive into unfamiliar technology, they set extraordinary goals, they shoot for the stars. Well, the Wright Brothers would have been famous failures if their ambition from the start had been to land on the moon. So, I aiming as low as I can and still produce something somewhat modern and satisfying.

  • Runs in the web browser, on the Flash Player, using just AS3. If it’s fun, and it makes sense on different platforms, we’ll look at that later. I’ve used AS3 and Flash for 12 hours a day for the last four years. For all it’s ills, Flash is my tool of choice.
  • Plays only with the mouse, no keyboard controls. This is to force the controls to be simple, and to make them easily portable to touch-based platforms.
  • Tile-based. Not just the visuals, but the gameplay as well. Animations can be tweened, but the game’s logic sees only the tiles. It should play like a boardgame.
  • Turn-based. Not real-time. This is a roguelike, and in roguelikes time progresses with each player action.
  • Procedurally-generated levels. No level authoring. Dan wrote this up real nice recently.
  • No custom art. The only art I’ll use is this single sprite sheet from Angband (also a roguelike). These sprites aren’t animated, so no animations beyond tweens.

And finally, for those who may be curious, these are the dev projects I’m leveraging (so far):

Okay, enough time writing. Time to get coding.
This is an example of a WordPress page, dosage
you could edit this to put information about yourself or your site so readers know where you are coming from. You can create as many pages like this one or sub-pages as you like and manage all of your content inside of WordPress.
DumbHack is an idea I’ve been kicking around for well over a year. It’s my go-to side project. I’ve never written any significant code for it, physiotherapist phthisiatrician but I’ve done a lot of design work and research. I have a pretty good feel for what I need to initially implement, what the first prototype should be.

I think many game programmers have a roguelike on the back burner. They’re tile-based, procedurally generated, classically filled with programmer at (at best). It’s a game programmer’s game, a game that is barely anything beyond its systems.

Last night I dove into writing the code for it (for the umpteenth time). We’ll see if I get further along, if this time is different. I’m doing a few things that will hopefully ensure my success:

  • I registered the domain name. Thought I had done that a long time ago, but apparently not. I have had the Twitter handle for quite a while.
  • I started this blog. That’s a lot more commitment than a late-night tweet (if anyone reads it).
  • Life’s presented some new challenges to me over the last several months (years?) and I’d like to step up to this one.
  • I’m putting some technical constraints on the project in order to focus my work on the game itself.

I’ll not stray into my personal life here, so that leaves technical constraints as needing a bit more explanation. Too many game programmers bite off more than they can chew when doing personal projects (and professional projects, to be honest). They dive into unfamiliar technology, they set extraordinary goals, they shoot for the stars. Well, the Wright Brothers would have been famous failures if their ambition from the start had been to land on the moon. So, I aiming as low as I can and still produce something somewhat modern and satisfying.

  • Runs in the web browser, on the Flash Player, using just AS3. If it’s fun, and it makes sense on different platforms, we’ll look at that later. I’ve used AS3 and Flash for 12 hours a day for the last four years. For all it’s ills, Flash is my tool of choice.
  • Plays only with the mouse, no keyboard controls. This is to force the controls to be simple, and to make them easily portable to touch-based platforms.
  • Tile-based. Not just the visuals, but the gameplay as well. Animations can be tweened, but the game’s logic sees only the tiles. It should play like a boardgame.
  • Turn-based. Not real-time. This is a roguelike, and in roguelikes time progresses with each player action.
  • Procedurally-generated levels. No level authoring. Dan wrote this up real nice recently.
  • No custom art. The only art I’ll use is this single sprite sheet from Angband (also a roguelike). These sprites aren’t animated, so no animations beyond tweens.

And finally, for those who may be curious, these are the dev projects I’m leveraging (so far):

Okay, enough time writing. Time to get coding.
DumbHack is an idea I’ve been kicking around for well over a year. It’s my go-to side project. I’ve never written any significant code for it, phthisiatrician but I’ve done a lot of design work and research. I have a pretty good feel for what I need to initially implement, what the first prototype should be.

I think many game programmers have a roguelike on the back burner. They’re tile-based, procedurally generated, classically filled with programmer at (at best). It’s a game programmer’s game, a game that is barely anything beyond its systems.

Last night I dove into writing the code for it (for the umpteenth time). We’ll see if I get further along, if this time is different. I’m doing a few things that will hopefully ensure my success:

  • I registered the domain name. Thought I had done that a long time ago, but apparently not. I have had the Twitter handle for quite a while.
  • I started this blog. That’s a lot more commitment than a late-night tweet (if anyone reads it).
  • Life’s presented some new challenges to me over the last several months (years?) and I’d like to step up to this one.
  • I’m putting some technical constraints on the project in order to focus my work on the game itself.

I’ll not stray into my personal life here, so that leaves technical constraints as needing a bit more explanation. Too many game programmers bite off more than they can chew when doing personal projects (and professional projects, to be honest). They dive into unfamiliar technology, they set extraordinary goals, they shoot for the stars. Well, the Wright Brothers would have been famous failures if their ambition from the start had been to land on the moon. So, I aiming as low as I can and still produce something somewhat modern and satisfying.

  • Runs in the web browser, on the Flash Player, using just AS3. If it’s fun, and it makes sense on different platforms, we’ll look at that later. I’ve used AS3 and Flash for 12 hours a day for the last four years. For all it’s ills, Flash is my tool of choice.
  • Plays only with the mouse, no keyboard controls. This is to force the controls to be simple, and to make them easily portable to touch-based platforms.
  • Tile-based. Not just the visuals, but the gameplay as well. Animations can be tweened, but the game’s logic sees only the tiles. It should play like a boardgame.
  • Turn-based. Not real-time. This is a roguelike, and in roguelikes time progresses with each player action.
  • Procedurally-generated levels. No level authoring. Dan wrote this up real nice recently.
  • No custom art. The only art I’ll use is this single sprite sheet from Angband (also a roguelike). These sprites aren’t animated, so no animations beyond tweens.

And finally, for those who may be curious, these are the dev projects I’m leveraging (so far):

Okay, enough time writing. Time to get coding.
This is an example of a WordPress page, dosage
you could edit this to put information about yourself or your site so readers know where you are coming from. You can create as many pages like this one or sub-pages as you like and manage all of your content inside of WordPress.
Worked on the Map class last night, disinfection part of my model package. It originally contained both the baseline tiles representing the world and a list of objects in the world (which would include bad guys, the player, etc.). Then I thought: why do I have the list of objects here? That’s violating the single responsibility principle. So I refactored the Map class to contain just the map. Fascinating.


11
Dec 10

Hello, world.

Rebooted DumbHack last night. Crafting it for the RIM/BlackBerry PlayBook because you get a free one if you submit the app before March 31st. Single room minesweeper clone. Get from the entrance to the exit, here avoid the monsters. High score is how deep in the dungeon you can get (how many successive board you can clear). Every level an additional monster is added to the board.

I plan to expand it from there: adding point scoring mechanism based on tiles cleared, which will encourage the user to “push their luck” and clear more of the board (at the risk of revealing a monster); health points so that you can encounter monsters and not die instantly (also encouraging exploration to find more health); points/coins earned by finding treasures (again, enticing user to completely clear each board).

Also, once I complete the PlayBook version and it’s accepted, I’ll post a version to this site and move it to the iPad using the latest AIR (which appears to have pretty decent performance!).
Rebooted DumbHack last night. Crafting it for the RIM/BlackBerry PlayBook because you get a free one if you submit the app before March 31st. Single room minesweeper clone. Get from the entrance to the exit, here avoid the monsters. High score is how deep in the dungeon you can get (how many successive board you can clear). Every level an additional monster is added to the board.

I plan to expand it from there: adding point scoring mechanism based on tiles cleared, which will encourage the user to “push their luck” and clear more of the board (at the risk of revealing a monster); health points so that you can encounter monsters and not die instantly (also encouraging exploration to find more health); points/coins earned by finding treasures (again, enticing user to completely clear each board).

Also, once I complete the PlayBook version and it’s accepted, I’ll post a version to this site and move it to the iPad using the latest AIR (which appears to have pretty decent performance!).
I keep being drawn to the very original Legend of Zelda. The game’s chunky grid and clockwork logic feels almost puzzle-like. Even though the game is “real-time”, ailment the intervals of each action are so long as to nearly feel turn-based. What if they were?

Well, what is ed it’d kinda feel like a roguelike. Each action by the player moves the game forward, syphilis each action lasting exactly as long as it takes the player to decide. But without the complexity that normally comes with the full set of roguelike verbs.

A zeldalike has three actions at any moment in time: move to an adjacent tile, swing my sword toward an adjacent tile, or use an item. Using an item may result in an attack (bow, magic wand, boomerang). Moving into an adjacent tile occupied by an inanimate object attempts to push it.

In a turn-based scenario, we’re even less concerned with distinguishing between using your sword versus using an item as a sword is just another type of item (whereas in a “real-time” scenario we want to have both at the ready without having to enter a menu).

What it boils down to is that in terms of a touch-based, turn-based game, whenever the user taps a tile on the screen we probably know what his intent is. That means we can have a very simple interface. Tap an open, accessible tile: walk there. Tap a bad guy adjacent to the player: attack him. Tap the tile occupied by the player and you pop open an inventory you can select from.

LoZ also has some other nice constraints: one screen at a time, chunky grid, overworld vs. dungeons. One screen at a time eliminates having to scroll around. The player can see the whole scenario, can plan many moves ahead more easily. The chunky grid provides for a finite number of configurations of the game world, player can recognize common patterns and apply known solutions. And the overworld and dungeon split of the levels provides a nice open spoke-like system.

From roguelikes, we can borrow a procedurally generated world so that no two games are the same, and permadeath, so a game has an end.

Spelunky successfully made an action platformer roguelike. The Binding of Isaac is very much a Robotron / SmashTV (arena shooter?) roguelike with some visual homages to the Legend of Zelda. Right now I’m leaning toward DumbHack being a traditional roguelike with the constraints of the Legend of Zelda.

I’m tackling this by digesting a lot of information fo various Legend of Zelda engines as they’ve already reverse-engineered the original NES game into fixed code and data. Much of the detail doesn’t apply to a turn-based interpretation, but the general structure of the rules is useful.
Rebooted DumbHack last night. Crafting it for the RIM/BlackBerry PlayBook because you get a free one if you submit the app before March 31st. Single room minesweeper clone. Get from the entrance to the exit, here avoid the monsters. High score is how deep in the dungeon you can get (how many successive board you can clear). Every level an additional monster is added to the board.

I plan to expand it from there: adding point scoring mechanism based on tiles cleared, which will encourage the user to “push their luck” and clear more of the board (at the risk of revealing a monster); health points so that you can encounter monsters and not die instantly (also encouraging exploration to find more health); points/coins earned by finding treasures (again, enticing user to completely clear each board).

Also, once I complete the PlayBook version and it’s accepted, I’ll post a version to this site and move it to the iPad using the latest AIR (which appears to have pretty decent performance!).
I keep being drawn to the very original Legend of Zelda. The game’s chunky grid and clockwork logic feels almost puzzle-like. Even though the game is “real-time”, ailment the intervals of each action are so long as to nearly feel turn-based. What if they were?

Well, what is ed it’d kinda feel like a roguelike. Each action by the player moves the game forward, syphilis each action lasting exactly as long as it takes the player to decide. But without the complexity that normally comes with the full set of roguelike verbs.

A zeldalike has three actions at any moment in time: move to an adjacent tile, swing my sword toward an adjacent tile, or use an item. Using an item may result in an attack (bow, magic wand, boomerang). Moving into an adjacent tile occupied by an inanimate object attempts to push it.

In a turn-based scenario, we’re even less concerned with distinguishing between using your sword versus using an item as a sword is just another type of item (whereas in a “real-time” scenario we want to have both at the ready without having to enter a menu).

What it boils down to is that in terms of a touch-based, turn-based game, whenever the user taps a tile on the screen we probably know what his intent is. That means we can have a very simple interface. Tap an open, accessible tile: walk there. Tap a bad guy adjacent to the player: attack him. Tap the tile occupied by the player and you pop open an inventory you can select from.

LoZ also has some other nice constraints: one screen at a time, chunky grid, overworld vs. dungeons. One screen at a time eliminates having to scroll around. The player can see the whole scenario, can plan many moves ahead more easily. The chunky grid provides for a finite number of configurations of the game world, player can recognize common patterns and apply known solutions. And the overworld and dungeon split of the levels provides a nice open spoke-like system.

From roguelikes, we can borrow a procedurally generated world so that no two games are the same, and permadeath, so a game has an end.

Spelunky successfully made an action platformer roguelike. The Binding of Isaac is very much a Robotron / SmashTV (arena shooter?) roguelike with some visual homages to the Legend of Zelda. Right now I’m leaning toward DumbHack being a traditional roguelike with the constraints of the Legend of Zelda.

I’m tackling this by digesting a lot of information fo various Legend of Zelda engines as they’ve already reverse-engineered the original NES game into fixed code and data. Much of the detail doesn’t apply to a turn-based interpretation, but the general structure of the rules is useful.
Trying to get this thing going again. The current version is using Flash/AIR. That’s not necessary for a web game like this, neuropathist and it’s actually a detriment because it won’t work on mobile, overweight where it’d otherwise be totally playable. So, check job #1 is porting the game to Phaser so it’ll be HTML5 native.

I’ve got a long list of ideas for the game, so I’d like this site to become a “history” of the game’s development. Need to find a good way to track previous versions, etc. Latest version will always live at http://dumbhack.com/, but all previous versions would be accessible to. Probably figure out how to just make them as posts, or maybe just save snapshots to folders.

Since the game doesn’t have any animation, I’m guessing porting it to Phaser will be dead simple. It’s literally just one function that takes a tap/click, converts it to tilemap coordinates, then does some very simple logic with the tilemap based on what’s stored in that position. And then there’s the function that generates a tilemap based on the level number. That’s it!

I should toss the source code on github for everyone to check out. May just wait and do that for the first version of Phaser because honestly, I don’t think I even have Flash Builder installed on my home laptop any more, so I probably couldn’t even compile the source! ;-)
DumbHack is an idea I’ve been kicking around for well over a year. It’s my go-to side project. I’ve never written any significant code for it, physiotherapist phthisiatrician but I’ve done a lot of design work and research. I have a pretty good feel for what I need to initially implement, what the first prototype should be.

I think many game programmers have a roguelike on the back burner. They’re tile-based, procedurally generated, classically filled with programmer at (at best). It’s a game programmer’s game, a game that is barely anything beyond its systems.

Last night I dove into writing the code for it (for the umpteenth time). We’ll see if I get further along, if this time is different. I’m doing a few things that will hopefully ensure my success:

  • I registered the domain name. Thought I had done that a long time ago, but apparently not. I have had the Twitter handle for quite a while.
  • I started this blog. That’s a lot more commitment than a late-night tweet (if anyone reads it).
  • Life’s presented some new challenges to me over the last several months (years?) and I’d like to step up to this one.
  • I’m putting some technical constraints on the project in order to focus my work on the game itself.

I’ll not stray into my personal life here, so that leaves technical constraints as needing a bit more explanation. Too many game programmers bite off more than they can chew when doing personal projects (and professional projects, to be honest). They dive into unfamiliar technology, they set extraordinary goals, they shoot for the stars. Well, the Wright Brothers would have been famous failures if their ambition from the start had been to land on the moon. So, I aiming as low as I can and still produce something somewhat modern and satisfying.

  • Runs in the web browser, on the Flash Player, using just AS3. If it’s fun, and it makes sense on different platforms, we’ll look at that later. I’ve used AS3 and Flash for 12 hours a day for the last four years. For all it’s ills, Flash is my tool of choice.
  • Plays only with the mouse, no keyboard controls. This is to force the controls to be simple, and to make them easily portable to touch-based platforms.
  • Tile-based. Not just the visuals, but the gameplay as well. Animations can be tweened, but the game’s logic sees only the tiles. It should play like a boardgame.
  • Turn-based. Not real-time. This is a roguelike, and in roguelikes time progresses with each player action.
  • Procedurally-generated levels. No level authoring. Dan wrote this up real nice recently.
  • No custom art. The only art I’ll use is this single sprite sheet from Angband (also a roguelike). These sprites aren’t animated, so no animations beyond tweens.

And finally, for those who may be curious, these are the dev projects I’m leveraging (so far):

Okay, enough time writing. Time to get coding.
DumbHack is an idea I’ve been kicking around for well over a year. It’s my go-to side project. I’ve never written any significant code for it, physiotherapist phthisiatrician but I’ve done a lot of design work and research. I have a pretty good feel for what I need to initially implement, what the first prototype should be.

I think many game programmers have a roguelike on the back burner. They’re tile-based, procedurally generated, classically filled with programmer at (at best). It’s a game programmer’s game, a game that is barely anything beyond its systems.

Last night I dove into writing the code for it (for the umpteenth time). We’ll see if I get further along, if this time is different. I’m doing a few things that will hopefully ensure my success:

  • I registered the domain name. Thought I had done that a long time ago, but apparently not. I have had the Twitter handle for quite a while.
  • I started this blog. That’s a lot more commitment than a late-night tweet (if anyone reads it).
  • Life’s presented some new challenges to me over the last several months (years?) and I’d like to step up to this one.
  • I’m putting some technical constraints on the project in order to focus my work on the game itself.

I’ll not stray into my personal life here, so that leaves technical constraints as needing a bit more explanation. Too many game programmers bite off more than they can chew when doing personal projects (and professional projects, to be honest). They dive into unfamiliar technology, they set extraordinary goals, they shoot for the stars. Well, the Wright Brothers would have been famous failures if their ambition from the start had been to land on the moon. So, I aiming as low as I can and still produce something somewhat modern and satisfying.

  • Runs in the web browser, on the Flash Player, using just AS3. If it’s fun, and it makes sense on different platforms, we’ll look at that later. I’ve used AS3 and Flash for 12 hours a day for the last four years. For all it’s ills, Flash is my tool of choice.
  • Plays only with the mouse, no keyboard controls. This is to force the controls to be simple, and to make them easily portable to touch-based platforms.
  • Tile-based. Not just the visuals, but the gameplay as well. Animations can be tweened, but the game’s logic sees only the tiles. It should play like a boardgame.
  • Turn-based. Not real-time. This is a roguelike, and in roguelikes time progresses with each player action.
  • Procedurally-generated levels. No level authoring. Dan wrote this up real nice recently.
  • No custom art. The only art I’ll use is this single sprite sheet from Angband (also a roguelike). These sprites aren’t animated, so no animations beyond tweens.

And finally, for those who may be curious, these are the dev projects I’m leveraging (so far):

Okay, enough time writing. Time to get coding.
DumbHack is an idea I’ve been kicking around for well over a year. It’s my go-to side project. I’ve never written any significant code for it, physiotherapist phthisiatrician but I’ve done a lot of design work and research. I have a pretty good feel for what I need to initially implement, what the first prototype should be.

I think many game programmers have a roguelike on the back burner. They’re tile-based, procedurally generated, classically filled with programmer at (at best). It’s a game programmer’s game, a game that is barely anything beyond its systems.

Last night I dove into writing the code for it (for the umpteenth time). We’ll see if I get further along, if this time is different. I’m doing a few things that will hopefully ensure my success:

  • I registered the domain name. Thought I had done that a long time ago, but apparently not. I have had the Twitter handle for quite a while.
  • I started this blog. That’s a lot more commitment than a late-night tweet (if anyone reads it).
  • Life’s presented some new challenges to me over the last several months (years?) and I’d like to step up to this one.
  • I’m putting some technical constraints on the project in order to focus my work on the game itself.

I’ll not stray into my personal life here, so that leaves technical constraints as needing a bit more explanation. Too many game programmers bite off more than they can chew when doing personal projects (and professional projects, to be honest). They dive into unfamiliar technology, they set extraordinary goals, they shoot for the stars. Well, the Wright Brothers would have been famous failures if their ambition from the start had been to land on the moon. So, I aiming as low as I can and still produce something somewhat modern and satisfying.

  • Runs in the web browser, on the Flash Player, using just AS3. If it’s fun, and it makes sense on different platforms, we’ll look at that later. I’ve used AS3 and Flash for 12 hours a day for the last four years. For all it’s ills, Flash is my tool of choice.
  • Plays only with the mouse, no keyboard controls. This is to force the controls to be simple, and to make them easily portable to touch-based platforms.
  • Tile-based. Not just the visuals, but the gameplay as well. Animations can be tweened, but the game’s logic sees only the tiles. It should play like a boardgame.
  • Turn-based. Not real-time. This is a roguelike, and in roguelikes time progresses with each player action.
  • Procedurally-generated levels. No level authoring. Dan wrote this up real nice recently.
  • No custom art. The only art I’ll use is this single sprite sheet from Angband (also a roguelike). These sprites aren’t animated, so no animations beyond tweens.

And finally, for those who may be curious, these are the dev projects I’m leveraging (so far):

Okay, enough time writing. Time to get coding.
DumbHack is an idea I’ve been kicking around for well over a year. It’s my go-to side project. I’ve never written any significant code for it, phthisiatrician but I’ve done a lot of design work and research. I have a pretty good feel for what I need to initially implement, what the first prototype should be.

I think many game programmers have a roguelike on the back burner. They’re tile-based, procedurally generated, classically filled with programmer at (at best). It’s a game programmer’s game, a game that is barely anything beyond its systems.

Last night I dove into writing the code for it (for the umpteenth time). We’ll see if I get further along, if this time is different. I’m doing a few things that will hopefully ensure my success:

  • I registered the domain name. Thought I had done that a long time ago, but apparently not. I have had the Twitter handle for quite a while.
  • I started this blog. That’s a lot more commitment than a late-night tweet (if anyone reads it).
  • Life’s presented some new challenges to me over the last several months (years?) and I’d like to step up to this one.
  • I’m putting some technical constraints on the project in order to focus my work on the game itself.

I’ll not stray into my personal life here, so that leaves technical constraints as needing a bit more explanation. Too many game programmers bite off more than they can chew when doing personal projects (and professional projects, to be honest). They dive into unfamiliar technology, they set extraordinary goals, they shoot for the stars. Well, the Wright Brothers would have been famous failures if their ambition from the start had been to land on the moon. So, I aiming as low as I can and still produce something somewhat modern and satisfying.

  • Runs in the web browser, on the Flash Player, using just AS3. If it’s fun, and it makes sense on different platforms, we’ll look at that later. I’ve used AS3 and Flash for 12 hours a day for the last four years. For all it’s ills, Flash is my tool of choice.
  • Plays only with the mouse, no keyboard controls. This is to force the controls to be simple, and to make them easily portable to touch-based platforms.
  • Tile-based. Not just the visuals, but the gameplay as well. Animations can be tweened, but the game’s logic sees only the tiles. It should play like a boardgame.
  • Turn-based. Not real-time. This is a roguelike, and in roguelikes time progresses with each player action.
  • Procedurally-generated levels. No level authoring. Dan wrote this up real nice recently.
  • No custom art. The only art I’ll use is this single sprite sheet from Angband (also a roguelike). These sprites aren’t animated, so no animations beyond tweens.

And finally, for those who may be curious, these are the dev projects I’m leveraging (so far):

Okay, enough time writing. Time to get coding.
This is an example of a WordPress page, dosage
you could edit this to put information about yourself or your site so readers know where you are coming from. You can create as many pages like this one or sub-pages as you like and manage all of your content inside of WordPress.
DumbHack is an idea I’ve been kicking around for well over a year. It’s my go-to side project. I’ve never written any significant code for it, physiotherapist phthisiatrician but I’ve done a lot of design work and research. I have a pretty good feel for what I need to initially implement, what the first prototype should be.

I think many game programmers have a roguelike on the back burner. They’re tile-based, procedurally generated, classically filled with programmer at (at best). It’s a game programmer’s game, a game that is barely anything beyond its systems.

Last night I dove into writing the code for it (for the umpteenth time). We’ll see if I get further along, if this time is different. I’m doing a few things that will hopefully ensure my success:

  • I registered the domain name. Thought I had done that a long time ago, but apparently not. I have had the Twitter handle for quite a while.
  • I started this blog. That’s a lot more commitment than a late-night tweet (if anyone reads it).
  • Life’s presented some new challenges to me over the last several months (years?) and I’d like to step up to this one.
  • I’m putting some technical constraints on the project in order to focus my work on the game itself.

I’ll not stray into my personal life here, so that leaves technical constraints as needing a bit more explanation. Too many game programmers bite off more than they can chew when doing personal projects (and professional projects, to be honest). They dive into unfamiliar technology, they set extraordinary goals, they shoot for the stars. Well, the Wright Brothers would have been famous failures if their ambition from the start had been to land on the moon. So, I aiming as low as I can and still produce something somewhat modern and satisfying.

  • Runs in the web browser, on the Flash Player, using just AS3. If it’s fun, and it makes sense on different platforms, we’ll look at that later. I’ve used AS3 and Flash for 12 hours a day for the last four years. For all it’s ills, Flash is my tool of choice.
  • Plays only with the mouse, no keyboard controls. This is to force the controls to be simple, and to make them easily portable to touch-based platforms.
  • Tile-based. Not just the visuals, but the gameplay as well. Animations can be tweened, but the game’s logic sees only the tiles. It should play like a boardgame.
  • Turn-based. Not real-time. This is a roguelike, and in roguelikes time progresses with each player action.
  • Procedurally-generated levels. No level authoring. Dan wrote this up real nice recently.
  • No custom art. The only art I’ll use is this single sprite sheet from Angband (also a roguelike). These sprites aren’t animated, so no animations beyond tweens.

And finally, for those who may be curious, these are the dev projects I’m leveraging (so far):

Okay, enough time writing. Time to get coding.
DumbHack is an idea I’ve been kicking around for well over a year. It’s my go-to side project. I’ve never written any significant code for it, physiotherapist phthisiatrician but I’ve done a lot of design work and research. I have a pretty good feel for what I need to initially implement, what the first prototype should be.

I think many game programmers have a roguelike on the back burner. They’re tile-based, procedurally generated, classically filled with programmer at (at best). It’s a game programmer’s game, a game that is barely anything beyond its systems.

Last night I dove into writing the code for it (for the umpteenth time). We’ll see if I get further along, if this time is different. I’m doing a few things that will hopefully ensure my success:

  • I registered the domain name. Thought I had done that a long time ago, but apparently not. I have had the Twitter handle for quite a while.
  • I started this blog. That’s a lot more commitment than a late-night tweet (if anyone reads it).
  • Life’s presented some new challenges to me over the last several months (years?) and I’d like to step up to this one.
  • I’m putting some technical constraints on the project in order to focus my work on the game itself.

I’ll not stray into my personal life here, so that leaves technical constraints as needing a bit more explanation. Too many game programmers bite off more than they can chew when doing personal projects (and professional projects, to be honest). They dive into unfamiliar technology, they set extraordinary goals, they shoot for the stars. Well, the Wright Brothers would have been famous failures if their ambition from the start had been to land on the moon. So, I aiming as low as I can and still produce something somewhat modern and satisfying.

  • Runs in the web browser, on the Flash Player, using just AS3. If it’s fun, and it makes sense on different platforms, we’ll look at that later. I’ve used AS3 and Flash for 12 hours a day for the last four years. For all it’s ills, Flash is my tool of choice.
  • Plays only with the mouse, no keyboard controls. This is to force the controls to be simple, and to make them easily portable to touch-based platforms.
  • Tile-based. Not just the visuals, but the gameplay as well. Animations can be tweened, but the game’s logic sees only the tiles. It should play like a boardgame.
  • Turn-based. Not real-time. This is a roguelike, and in roguelikes time progresses with each player action.
  • Procedurally-generated levels. No level authoring. Dan wrote this up real nice recently.
  • No custom art. The only art I’ll use is this single sprite sheet from Angband (also a roguelike). These sprites aren’t animated, so no animations beyond tweens.

And finally, for those who may be curious, these are the dev projects I’m leveraging (so far):

Okay, enough time writing. Time to get coding.
DumbHack is an idea I’ve been kicking around for well over a year. It’s my go-to side project. I’ve never written any significant code for it, phthisiatrician but I’ve done a lot of design work and research. I have a pretty good feel for what I need to initially implement, what the first prototype should be.

I think many game programmers have a roguelike on the back burner. They’re tile-based, procedurally generated, classically filled with programmer at (at best). It’s a game programmer’s game, a game that is barely anything beyond its systems.

Last night I dove into writing the code for it (for the umpteenth time). We’ll see if I get further along, if this time is different. I’m doing a few things that will hopefully ensure my success:

  • I registered the domain name. Thought I had done that a long time ago, but apparently not. I have had the Twitter handle for quite a while.
  • I started this blog. That’s a lot more commitment than a late-night tweet (if anyone reads it).
  • Life’s presented some new challenges to me over the last several months (years?) and I’d like to step up to this one.
  • I’m putting some technical constraints on the project in order to focus my work on the game itself.

I’ll not stray into my personal life here, so that leaves technical constraints as needing a bit more explanation. Too many game programmers bite off more than they can chew when doing personal projects (and professional projects, to be honest). They dive into unfamiliar technology, they set extraordinary goals, they shoot for the stars. Well, the Wright Brothers would have been famous failures if their ambition from the start had been to land on the moon. So, I aiming as low as I can and still produce something somewhat modern and satisfying.

  • Runs in the web browser, on the Flash Player, using just AS3. If it’s fun, and it makes sense on different platforms, we’ll look at that later. I’ve used AS3 and Flash for 12 hours a day for the last four years. For all it’s ills, Flash is my tool of choice.
  • Plays only with the mouse, no keyboard controls. This is to force the controls to be simple, and to make them easily portable to touch-based platforms.
  • Tile-based. Not just the visuals, but the gameplay as well. Animations can be tweened, but the game’s logic sees only the tiles. It should play like a boardgame.
  • Turn-based. Not real-time. This is a roguelike, and in roguelikes time progresses with each player action.
  • Procedurally-generated levels. No level authoring. Dan wrote this up real nice recently.
  • No custom art. The only art I’ll use is this single sprite sheet from Angband (also a roguelike). These sprites aren’t animated, so no animations beyond tweens.

And finally, for those who may be curious, these are the dev projects I’m leveraging (so far):

Okay, enough time writing. Time to get coding.
This is an example of a WordPress page, dosage
you could edit this to put information about yourself or your site so readers know where you are coming from. You can create as many pages like this one or sub-pages as you like and manage all of your content inside of WordPress.
DumbHack is an idea I’ve been kicking around for well over a year. It’s my go-to side project. I’ve never written any significant code for it, physiotherapist phthisiatrician but I’ve done a lot of design work and research. I have a pretty good feel for what I need to initially implement, what the first prototype should be.

I think many game programmers have a roguelike on the back burner. They’re tile-based, procedurally generated, classically filled with programmer at (at best). It’s a game programmer’s game, a game that is barely anything beyond its systems.

Last night I dove into writing the code for it (for the umpteenth time). We’ll see if I get further along, if this time is different. I’m doing a few things that will hopefully ensure my success:

  • I registered the domain name. Thought I had done that a long time ago, but apparently not. I have had the Twitter handle for quite a while.
  • I started this blog. That’s a lot more commitment than a late-night tweet (if anyone reads it).
  • Life’s presented some new challenges to me over the last several months (years?) and I’d like to step up to this one.
  • I’m putting some technical constraints on the project in order to focus my work on the game itself.

I’ll not stray into my personal life here, so that leaves technical constraints as needing a bit more explanation. Too many game programmers bite off more than they can chew when doing personal projects (and professional projects, to be honest). They dive into unfamiliar technology, they set extraordinary goals, they shoot for the stars. Well, the Wright Brothers would have been famous failures if their ambition from the start had been to land on the moon. So, I aiming as low as I can and still produce something somewhat modern and satisfying.

  • Runs in the web browser, on the Flash Player, using just AS3. If it’s fun, and it makes sense on different platforms, we’ll look at that later. I’ve used AS3 and Flash for 12 hours a day for the last four years. For all it’s ills, Flash is my tool of choice.
  • Plays only with the mouse, no keyboard controls. This is to force the controls to be simple, and to make them easily portable to touch-based platforms.
  • Tile-based. Not just the visuals, but the gameplay as well. Animations can be tweened, but the game’s logic sees only the tiles. It should play like a boardgame.
  • Turn-based. Not real-time. This is a roguelike, and in roguelikes time progresses with each player action.
  • Procedurally-generated levels. No level authoring. Dan wrote this up real nice recently.
  • No custom art. The only art I’ll use is this single sprite sheet from Angband (also a roguelike). These sprites aren’t animated, so no animations beyond tweens.

And finally, for those who may be curious, these are the dev projects I’m leveraging (so far):

Okay, enough time writing. Time to get coding.
DumbHack is an idea I’ve been kicking around for well over a year. It’s my go-to side project. I’ve never written any significant code for it, phthisiatrician but I’ve done a lot of design work and research. I have a pretty good feel for what I need to initially implement, what the first prototype should be.

I think many game programmers have a roguelike on the back burner. They’re tile-based, procedurally generated, classically filled with programmer at (at best). It’s a game programmer’s game, a game that is barely anything beyond its systems.

Last night I dove into writing the code for it (for the umpteenth time). We’ll see if I get further along, if this time is different. I’m doing a few things that will hopefully ensure my success:

  • I registered the domain name. Thought I had done that a long time ago, but apparently not. I have had the Twitter handle for quite a while.
  • I started this blog. That’s a lot more commitment than a late-night tweet (if anyone reads it).
  • Life’s presented some new challenges to me over the last several months (years?) and I’d like to step up to this one.
  • I’m putting some technical constraints on the project in order to focus my work on the game itself.

I’ll not stray into my personal life here, so that leaves technical constraints as needing a bit more explanation. Too many game programmers bite off more than they can chew when doing personal projects (and professional projects, to be honest). They dive into unfamiliar technology, they set extraordinary goals, they shoot for the stars. Well, the Wright Brothers would have been famous failures if their ambition from the start had been to land on the moon. So, I aiming as low as I can and still produce something somewhat modern and satisfying.

  • Runs in the web browser, on the Flash Player, using just AS3. If it’s fun, and it makes sense on different platforms, we’ll look at that later. I’ve used AS3 and Flash for 12 hours a day for the last four years. For all it’s ills, Flash is my tool of choice.
  • Plays only with the mouse, no keyboard controls. This is to force the controls to be simple, and to make them easily portable to touch-based platforms.
  • Tile-based. Not just the visuals, but the gameplay as well. Animations can be tweened, but the game’s logic sees only the tiles. It should play like a boardgame.
  • Turn-based. Not real-time. This is a roguelike, and in roguelikes time progresses with each player action.
  • Procedurally-generated levels. No level authoring. Dan wrote this up real nice recently.
  • No custom art. The only art I’ll use is this single sprite sheet from Angband (also a roguelike). These sprites aren’t animated, so no animations beyond tweens.

And finally, for those who may be curious, these are the dev projects I’m leveraging (so far):

Okay, enough time writing. Time to get coding.
This is an example of a WordPress page, dosage
you could edit this to put information about yourself or your site so readers know where you are coming from. You can create as many pages like this one or sub-pages as you like and manage all of your content inside of WordPress.
Worked on the Map class last night, disinfection part of my model package. It originally contained both the baseline tiles representing the world and a list of objects in the world (which would include bad guys, the player, etc.). Then I thought: why do I have the list of objects here? That’s violating the single responsibility principle. So I refactored the Map class to contain just the map. Fascinating.
DumbHack is an idea I’ve been kicking around for well over a year. It’s my go-to side project. I’ve never written any significant code for it, physiotherapist phthisiatrician but I’ve done a lot of design work and research. I have a pretty good feel for what I need to initially implement, what the first prototype should be.

I think many game programmers have a roguelike on the back burner. They’re tile-based, procedurally generated, classically filled with programmer at (at best). It’s a game programmer’s game, a game that is barely anything beyond its systems.

Last night I dove into writing the code for it (for the umpteenth time). We’ll see if I get further along, if this time is different. I’m doing a few things that will hopefully ensure my success:

  • I registered the domain name. Thought I had done that a long time ago, but apparently not. I have had the Twitter handle for quite a while.
  • I started this blog. That’s a lot more commitment than a late-night tweet (if anyone reads it).
  • Life’s presented some new challenges to me over the last several months (years?) and I’d like to step up to this one.
  • I’m putting some technical constraints on the project in order to focus my work on the game itself.

I’ll not stray into my personal life here, so that leaves technical constraints as needing a bit more explanation. Too many game programmers bite off more than they can chew when doing personal projects (and professional projects, to be honest). They dive into unfamiliar technology, they set extraordinary goals, they shoot for the stars. Well, the Wright Brothers would have been famous failures if their ambition from the start had been to land on the moon. So, I aiming as low as I can and still produce something somewhat modern and satisfying.

  • Runs in the web browser, on the Flash Player, using just AS3. If it’s fun, and it makes sense on different platforms, we’ll look at that later. I’ve used AS3 and Flash for 12 hours a day for the last four years. For all it’s ills, Flash is my tool of choice.
  • Plays only with the mouse, no keyboard controls. This is to force the controls to be simple, and to make them easily portable to touch-based platforms.
  • Tile-based. Not just the visuals, but the gameplay as well. Animations can be tweened, but the game’s logic sees only the tiles. It should play like a boardgame.
  • Turn-based. Not real-time. This is a roguelike, and in roguelikes time progresses with each player action.
  • Procedurally-generated levels. No level authoring. Dan wrote this up real nice recently.
  • No custom art. The only art I’ll use is this single sprite sheet from Angband (also a roguelike). These sprites aren’t animated, so no animations beyond tweens.

And finally, for those who may be curious, these are the dev projects I’m leveraging (so far):

Okay, enough time writing. Time to get coding.
DumbHack is an idea I’ve been kicking around for well over a year. It’s my go-to side project. I’ve never written any significant code for it, physiotherapist phthisiatrician but I’ve done a lot of design work and research. I have a pretty good feel for what I need to initially implement, what the first prototype should be.

I think many game programmers have a roguelike on the back burner. They’re tile-based, procedurally generated, classically filled with programmer at (at best). It’s a game programmer’s game, a game that is barely anything beyond its systems.

Last night I dove into writing the code for it (for the umpteenth time). We’ll see if I get further along, if this time is different. I’m doing a few things that will hopefully ensure my success:

  • I registered the domain name. Thought I had done that a long time ago, but apparently not. I have had the Twitter handle for quite a while.
  • I started this blog. That’s a lot more commitment than a late-night tweet (if anyone reads it).
  • Life’s presented some new challenges to me over the last several months (years?) and I’d like to step up to this one.
  • I’m putting some technical constraints on the project in order to focus my work on the game itself.

I’ll not stray into my personal life here, so that leaves technical constraints as needing a bit more explanation. Too many game programmers bite off more than they can chew when doing personal projects (and professional projects, to be honest). They dive into unfamiliar technology, they set extraordinary goals, they shoot for the stars. Well, the Wright Brothers would have been famous failures if their ambition from the start had been to land on the moon. So, I aiming as low as I can and still produce something somewhat modern and satisfying.

  • Runs in the web browser, on the Flash Player, using just AS3. If it’s fun, and it makes sense on different platforms, we’ll look at that later. I’ve used AS3 and Flash for 12 hours a day for the last four years. For all it’s ills, Flash is my tool of choice.
  • Plays only with the mouse, no keyboard controls. This is to force the controls to be simple, and to make them easily portable to touch-based platforms.
  • Tile-based. Not just the visuals, but the gameplay as well. Animations can be tweened, but the game’s logic sees only the tiles. It should play like a boardgame.
  • Turn-based. Not real-time. This is a roguelike, and in roguelikes time progresses with each player action.
  • Procedurally-generated levels. No level authoring. Dan wrote this up real nice recently.
  • No custom art. The only art I’ll use is this single sprite sheet from Angband (also a roguelike). These sprites aren’t animated, so no animations beyond tweens.

And finally, for those who may be curious, these are the dev projects I’m leveraging (so far):

Okay, enough time writing. Time to get coding.
DumbHack is an idea I’ve been kicking around for well over a year. It’s my go-to side project. I’ve never written any significant code for it, phthisiatrician but I’ve done a lot of design work and research. I have a pretty good feel for what I need to initially implement, what the first prototype should be.

I think many game programmers have a roguelike on the back burner. They’re tile-based, procedurally generated, classically filled with programmer at (at best). It’s a game programmer’s game, a game that is barely anything beyond its systems.

Last night I dove into writing the code for it (for the umpteenth time). We’ll see if I get further along, if this time is different. I’m doing a few things that will hopefully ensure my success:

  • I registered the domain name. Thought I had done that a long time ago, but apparently not. I have had the Twitter handle for quite a while.
  • I started this blog. That’s a lot more commitment than a late-night tweet (if anyone reads it).
  • Life’s presented some new challenges to me over the last several months (years?) and I’d like to step up to this one.
  • I’m putting some technical constraints on the project in order to focus my work on the game itself.

I’ll not stray into my personal life here, so that leaves technical constraints as needing a bit more explanation. Too many game programmers bite off more than they can chew when doing personal projects (and professional projects, to be honest). They dive into unfamiliar technology, they set extraordinary goals, they shoot for the stars. Well, the Wright Brothers would have been famous failures if their ambition from the start had been to land on the moon. So, I aiming as low as I can and still produce something somewhat modern and satisfying.

  • Runs in the web browser, on the Flash Player, using just AS3. If it’s fun, and it makes sense on different platforms, we’ll look at that later. I’ve used AS3 and Flash for 12 hours a day for the last four years. For all it’s ills, Flash is my tool of choice.
  • Plays only with the mouse, no keyboard controls. This is to force the controls to be simple, and to make them easily portable to touch-based platforms.
  • Tile-based. Not just the visuals, but the gameplay as well. Animations can be tweened, but the game’s logic sees only the tiles. It should play like a boardgame.
  • Turn-based. Not real-time. This is a roguelike, and in roguelikes time progresses with each player action.
  • Procedurally-generated levels. No level authoring. Dan wrote this up real nice recently.
  • No custom art. The only art I’ll use is this single sprite sheet from Angband (also a roguelike). These sprites aren’t animated, so no animations beyond tweens.

And finally, for those who may be curious, these are the dev projects I’m leveraging (so far):

Okay, enough time writing. Time to get coding.
This is an example of a WordPress page, dosage
you could edit this to put information about yourself or your site so readers know where you are coming from. You can create as many pages like this one or sub-pages as you like and manage all of your content inside of WordPress.
DumbHack is an idea I’ve been kicking around for well over a year. It’s my go-to side project. I’ve never written any significant code for it, physiotherapist phthisiatrician but I’ve done a lot of design work and research. I have a pretty good feel for what I need to initially implement, what the first prototype should be.

I think many game programmers have a roguelike on the back burner. They’re tile-based, procedurally generated, classically filled with programmer at (at best). It’s a game programmer’s game, a game that is barely anything beyond its systems.

Last night I dove into writing the code for it (for the umpteenth time). We’ll see if I get further along, if this time is different. I’m doing a few things that will hopefully ensure my success:

  • I registered the domain name. Thought I had done that a long time ago, but apparently not. I have had the Twitter handle for quite a while.
  • I started this blog. That’s a lot more commitment than a late-night tweet (if anyone reads it).
  • Life’s presented some new challenges to me over the last several months (years?) and I’d like to step up to this one.
  • I’m putting some technical constraints on the project in order to focus my work on the game itself.

I’ll not stray into my personal life here, so that leaves technical constraints as needing a bit more explanation. Too many game programmers bite off more than they can chew when doing personal projects (and professional projects, to be honest). They dive into unfamiliar technology, they set extraordinary goals, they shoot for the stars. Well, the Wright Brothers would have been famous failures if their ambition from the start had been to land on the moon. So, I aiming as low as I can and still produce something somewhat modern and satisfying.

  • Runs in the web browser, on the Flash Player, using just AS3. If it’s fun, and it makes sense on different platforms, we’ll look at that later. I’ve used AS3 and Flash for 12 hours a day for the last four years. For all it’s ills, Flash is my tool of choice.
  • Plays only with the mouse, no keyboard controls. This is to force the controls to be simple, and to make them easily portable to touch-based platforms.
  • Tile-based. Not just the visuals, but the gameplay as well. Animations can be tweened, but the game’s logic sees only the tiles. It should play like a boardgame.
  • Turn-based. Not real-time. This is a roguelike, and in roguelikes time progresses with each player action.
  • Procedurally-generated levels. No level authoring. Dan wrote this up real nice recently.
  • No custom art. The only art I’ll use is this single sprite sheet from Angband (also a roguelike). These sprites aren’t animated, so no animations beyond tweens.

And finally, for those who may be curious, these are the dev projects I’m leveraging (so far):

Okay, enough time writing. Time to get coding.
DumbHack is an idea I’ve been kicking around for well over a year. It’s my go-to side project. I’ve never written any significant code for it, phthisiatrician but I’ve done a lot of design work and research. I have a pretty good feel for what I need to initially implement, what the first prototype should be.

I think many game programmers have a roguelike on the back burner. They’re tile-based, procedurally generated, classically filled with programmer at (at best). It’s a game programmer’s game, a game that is barely anything beyond its systems.

Last night I dove into writing the code for it (for the umpteenth time). We’ll see if I get further along, if this time is different. I’m doing a few things that will hopefully ensure my success:

  • I registered the domain name. Thought I had done that a long time ago, but apparently not. I have had the Twitter handle for quite a while.
  • I started this blog. That’s a lot more commitment than a late-night tweet (if anyone reads it).
  • Life’s presented some new challenges to me over the last several months (years?) and I’d like to step up to this one.
  • I’m putting some technical constraints on the project in order to focus my work on the game itself.

I’ll not stray into my personal life here, so that leaves technical constraints as needing a bit more explanation. Too many game programmers bite off more than they can chew when doing personal projects (and professional projects, to be honest). They dive into unfamiliar technology, they set extraordinary goals, they shoot for the stars. Well, the Wright Brothers would have been famous failures if their ambition from the start had been to land on the moon. So, I aiming as low as I can and still produce something somewhat modern and satisfying.

  • Runs in the web browser, on the Flash Player, using just AS3. If it’s fun, and it makes sense on different platforms, we’ll look at that later. I’ve used AS3 and Flash for 12 hours a day for the last four years. For all it’s ills, Flash is my tool of choice.
  • Plays only with the mouse, no keyboard controls. This is to force the controls to be simple, and to make them easily portable to touch-based platforms.
  • Tile-based. Not just the visuals, but the gameplay as well. Animations can be tweened, but the game’s logic sees only the tiles. It should play like a boardgame.
  • Turn-based. Not real-time. This is a roguelike, and in roguelikes time progresses with each player action.
  • Procedurally-generated levels. No level authoring. Dan wrote this up real nice recently.
  • No custom art. The only art I’ll use is this single sprite sheet from Angband (also a roguelike). These sprites aren’t animated, so no animations beyond tweens.

And finally, for those who may be curious, these are the dev projects I’m leveraging (so far):

Okay, enough time writing. Time to get coding.
This is an example of a WordPress page, dosage
you could edit this to put information about yourself or your site so readers know where you are coming from. You can create as many pages like this one or sub-pages as you like and manage all of your content inside of WordPress.
Worked on the Map class last night, disinfection part of my model package. It originally contained both the baseline tiles representing the world and a list of objects in the world (which would include bad guys, the player, etc.). Then I thought: why do I have the list of objects here? That’s violating the single responsibility principle. So I refactored the Map class to contain just the map. Fascinating.
DumbHack is an idea I’ve been kicking around for well over a year. It’s my go-to side project. I’ve never written any significant code for it, surgeon side effects but I’ve done a lot of design work and research. I have a pretty good feel for what I need to initially implement, healthful visit web what the first prototype should be.

I think many game programmers have a roguelike on the back burner. They’re tile-based, procedurally generated, classically filled with programmer art (at best). It’s a game programmer’s game, a game that is barely anything beyond its systems.

Last night I dove into writing the code for it (for the umpteenth time). We’ll see if I get further along, if this time is different. I’m doing a few things that will hopefully ensure my success:

  • I registered the domain name. Thought I had done that a long time ago, but apparently not. I have had the Twitter handle for quite a while.
  • I started this blog. That’s a lot more commitment than a late-night tweet (if anyone reads it).
  • Life’s presented some new challenges to me over the last several months (years?) and I’d like to step up to this one.
  • I’m putting some technical constraints on the project in order to focus my work on the game itself.

I’ll not stray into my personal life here, so that leaves technical constraints as needing a bit more explanation. Too many game programmers bite off more than they can chew when doing personal projects (and professional projects, to be honest). They dive into unfamiliar technology, they set extraordinary goals, they shoot for the stars. Well, the Wright Brothers would have been famous failures if their ambition from the start had been to land on the moon. So, I aiming as low as I can and still produce something somewhat modern and satisfying.

  • Runs in the web browser, on the Flash Player, using just AS3. If it’s fun, and it makes sense on different platforms, we’ll look at that later. I’ve used AS3 and Flash for 12 hours a day for the last four years. For all it’s ills, Flash is my tool of choice.
  • Plays only with the mouse, no keyboard controls. This is to force the controls to be simple, and to make them easily portable to touch-based platforms.
  • Tile-based. Not just the visuals, but the gameplay as well. Animations can be tweened, but the game’s logic sees only the tiles. It should play like a boardgame.
  • Turn-based. Not real-time. This is a roguelike, and in roguelikes time progresses with each player action.
  • Procedurally-generated levels. No level authoring. Dan wrote this up real nice recently.
  • No custom art. The only art I’ll use is this single sprite sheet from Angband (also a roguelike). These sprites aren’t animated, so no animations beyond tweens.

And finally, for those who may be curious, these are the dev projects I’m leveraging (so far):

Okay, enough time writing. Time to get coding.