Sunday, December 15, 2013

Ludum Dare: I Dared

Whoa. I did it.

Here we see about 1.9% of the 48 Hour Competition entries for Ludum Dare 28.  Mine's third from the left on the bottom row.
Yep, I finished a game for Ludum Dare 28. And seriously, I'm actually surprised that I succeeded. I'd never created a full HTML5 game before, and I thought it was probably kind of a fool's errand to try to do one in less than 24 hours. But I made it.
(Less that 24 hours, but more than 12, at least. I wasn't needed continually at the movie shoot, and managed to get in a little work on the game there, and likewise a bit at the Solstice party. Still, if I had to estimate the total time I put in at the game, I... I guess I'd put it somewhere between 15 and 20 hours? I think?)

Oh, it's a flawed game, certainly. There's plenty I'd have liked to do differently, if I had more time. But it's a complete game, with five levels (though I'd have liked to have more, of course), and a working level editor.

If anyone wants to try it out, here's the game. And you can see the source files here, should you care to look.
The final art assets for the game.  There's so much blank space mostly because at first I'd intended to have multiple frames of animation for the player and monsters...
I guess maybe I should talk about the level editor a little more, since that's, you know, kind of supposed to be the subject of this blog and all. The level editor was actually the first part of the game I made, for the simple reason that I used it to make the levels, and before I could make the bit of actually playing the game, I needed to have levels to play.

In a recent post, I mentioned that the standard for tile-based editors was to have the user choose a tile from a menu, and then paint with those tiles. I went on to opine that it made since that this method was so widespread, since was probably the most user-friendly way of creating tile-based maps. That being the case, one might expect that I would use that method in making a level editor for a tile-based game of my own.

I didn't. No, I fell back on the old Lode Runner method of selecting tiles to lay down via a hotkey. (Though, unlike in Lode Runner, the tiles are actually placed with the mouse.) Why? Well, not because I thought it was really a better approach. Really, just because time was limited and it was easier to implement. That's it. Worse yet, there's no documentation of what key corresponds to what tile, so you have to figure it out by trial and error, I guess. In case anyone wants to make their own levels, though, here's a bit of a cheat sheet: (Tiles with more than one key listed can be placed in multiple directions; the keys listed correspond to the directions up, left, right, and down, in that order.)
Blank floor tile
Cracked Wall
Locked Door
Fireball Machine
Monster Type 1
Monster Type 2 (fireball spitter)
Monster Type 3 (invulnerable to arrows)

An early test of the level editor
I do not expect to win any awards. (I'm not sure what awards there are anyway.)   Even if there weren't more than 1200 entries (wow!), I'd be under no delusion that my first attempt at an HTML5 game would have any chance of placing. I wasn't in this for the competition. I'm just happy to have finished a game.

And hey, if I managed to finish a game on my first time attempting Ludum Dare, and after having gotten such a late start and having so many other commitments to deal with... yeah, I'm definitely doing this again next time. Unless it happens to fall on a weekend even busier than this one, I guess.

For the record, here are a few things I would have liked to have done differently, had I had more time:
  • Better graphics. Obviously. In particular, I'd have liked the player and the monsters to be animated. I'd originally intended for them to be, but I realized there'd be no time to do multiple frames of animation if I still wanted to have time left for the coding. Had I more time, I'd also intended for the player sprite to have different graphics for the direction he's facing. And maybe also for the item he chose.
  • More levels. This is another big one. Five levels is something, but it isn't much. I'd intended for a theme for the levels to be that there's a fairly obvious and straightforward way through with one item, but if you wanted to pick up the gem you'd have to use a different tool and take a less obvious and more tortuous route.
  • Better collision detection. Yeah. Sometimes the player kind of slides his shoulder through a wall. I was trying to improve this right up until the deadline, with limited success. I think I know now what I'd have to do to fix it, but of course now I don't have time.
  • Boundary enforcement. Unless your map is surrounded by walls, there's nothing prohibiting monsters, or even the player, from wandering off the edge of the map and getting lost. For this reason, I recommend surrounding all your maps by walls. (Though unfortunately I realized after the submission deadline has passed that there is a way to break out of the walls and wander out of bounds in one of the game's built-in levels... oh well.)
  • More error catching in general. The program's pretty sloppy right now in general as far as letting the user do things it probably shouldn't. For instance, it's possible to put in multiple starting points in a map. This doesn't crash the program, or anything—basically, because of how the program reads the map, I'm pretty sure it should just use the lowest starting point, or in the case of a tie the rightmost of those tied for lowest—but it still should probably have been disallowed.
  • As briefly referenced in the instructions, I'd wanted to have pressure plates that would create or cancel walls of energy or something elsewhere in the maps.  I realized pretty early on that I wasn't likely to have time to implement that, though, which is a bit of a pity since it could have led to some nice puzzles.
  • Sound. A scream when the player falls in a pit, a crackle of a fireball... would have added something.
  • A more attractive intro and instructions. The all-text intro that's there now was of course quick and easy to create, but some graphics and a better layout would have greatly improved it.
  • A better win routine, too. Slapping "You win!" over the screen in big letters is arguably somewhat anticlimactic.
  • Cookies to keep track of what level the player reached if he quits the game and comes back to it later.
  • Possibly implementing some simple data compression on the maps, so they're not all stored as strings exactly 256 characters long with lots of repetition.
  • A catchier name. Seriously. "Underequipped"? What was I thinking?

The screenshot of my game I submitted to the Ludum Dare site.
Next post will be about Eamon, I promise.

And for now... I'm going to get some sleep.

Here Goes Nothing: Ludum Dare 28

Well, I said I'd have more free time starting after the 9th, but that seems to have been a little premature; while I did have an important deadline to meet on the 9th, it turned out there was a little more to do that I got a few days' extension on, as well as other things to catch up on that I'd put off because of that deadline, so my schedule didn't clear up quite as quickly as I had (rather unreasonably) expected.

And I'm afraid this weekend I won't have another post on Eamon or 001 just yet. They're coming, I swear. There will be another post on Eamon soon. But something else came up this weekend that... kind of took priority.

See, in one of my first posts, reader Zenic Reverie posted a comment asking if I'd given any thought to participating in Ludum Dare. Now, Ludum Dare, for those who don't know (and didn't just follow that link to find out), is an activity that involves creating a complete game, from scratch, in 48 hours, following a given theme. I'd been aware of it before, and it's something I'd always sort of wanted to get into. I've participated in a number of other limited-time creation activities: NaNoWriMo, 24 Hour Comics Day, the 48 Hour Film Project. (Well, okay, that last isn't a solo activity, but I wrote the script and composed the score for a completed entry in the project.) As I posted in response to Zenic Reverie's question, "the main reason I haven't tried Ludum Dare is that I don't think I have enough experience in game creation to be able to work fast enough to create a game in 48 hours."

But then, I went on to write, I shouldn't let that stop me... I succeeded on my first attempt at 24 Hour Comics Day despite never having created a comic before. So I decided that yes, I'd go ahead and do it, "[a]ssuming it doesn't fall on a day I have a commitment I can't get out of".

A wallpaper showing all the games from Ludum Dare 21 (from here)

Well, I thought I was subscribed to the site and would get updates about Ludum Dare, but apparently not, because I didn't find out till a few days ago that Ludum Dare 28 was taking place... this weekend. As in, right now, as I post this. And unfortunately, I do have several commitments this weekend.

Also not helping matters is the fact that for some reason I'd assumed Ludum Dare started Saturday morning, when in fact it turns out it started Friday night, at about 6 p.m. Pacific Time. Had I known that (and really, there's no good excuse for my not having been more assiduous about checking the website for the exact starting time), I would have had a good extra evening to work on the game. As it was, I checked on Saturday morning to find that it had already started. Not that I had time to work on it that morning; I had several commitments that day, and while I was able to think about game ideas while driving to and from the places I needed to go, I wasn't able to actually get started on the game until around 6 p.m. Saturday. That means a full day lost.

And really, it's more than that, because I'm not without commitments Sunday, either. I have to be at a movie set at seven a.m., and then I've promised to come to a Solstice party in the afternoon. Which means really my window for working on the game ends before 6 a.m., and even if I stay up all night (which at this point I guess I will; there'll probably be coffee at the film set) I've really got less than twelve hours. (There's a chance I may have a sliver of time to work on it between the movie shoot and the Solstice party, or after said party, but it's not something I can count on.)

And of course that's not taking into account the time I'm taking to write this blog post, I guess.

What have I got done so far? Well... I've got the graphics. They're not great, but they'll do, I guess. That gives me a few hours to do all the coding.

My graphics, such as they are.  Pixel art is not my forte.

Oh... and as for what program I'm using to create the game, well, I'm not. I'm just coding an HTML5 game. I have worked a little with HTML5 canvas programming before, but never created a full game with it. So my attempting to write a full game in a few hours is... probably unrealistic. And yes, it has crossed my mind that this may be a hopeless cause, and that I should probably just give up. But... I want to do this, to set a precedent for myself. If I make excuses for not participating in Ludum Dare this time, even if they're really good excuses, then it's that much easier to make excuses for not doing it next time, too. But if I forge ahead and do my best to finish a game despite all my commitments and obstacles, then I'm that much more likely to do it next time. I don't expect to do well in the competition. I'm not sure I even really expect to finish the game. But I'm going to try. Yeah, it's possible the game won't get done. But if I don't make the attempt, it definitely won't get done.

The game will be called "Underequipped".

And, in keeping with the subject of my blog, it will include a level editor.

When and if I get it done.

Saturday, December 7, 2013

A Brief Glance Ahead

On the one hand, I have a big deadline on the 9th that I've really had to focus on, which means I haven't really had time to work further with Eamon (or any other game creation programs) and have more to blog about. On the other hand, I don't want to go more than a week without updating again. So, in a compromise likely to satisfy nobody, I decided to make a brief update today just outlining my plans for the blog's immediate future.

The good news is, though, that after the 9th, my free time should increase dramatically, and I ought to be able to post much more often for a while. Well, I do have further deadlines at the end of the year, but that's still a few weeks away, so I'll be able to justify devoting at least a little more time to the blog.

This image has something to do with what I'm working on.  That's all I'm saying.
So here are my plans for the next few posts: The next post is probably going to be a second look at Eamon; for several reasons, I planned to play a few more existing Eamon adventures before really getting into making mine. (As I think I mentioned in a previous post, I've already found a few things I was wrong about in my last Eamon-related post.) After that, I'll probably have a post on mapping in Eamon, followed by one about generating other content in Eamon, and finally on customization (i.e. editing the Eamon source code for effects specific to the adventure). Then probably a wrap-up post about Eamon. So... at least four more posts on Eamon, maybe more if it turns out I have enough to say about one of those aspects to fill multiple posts.

I expect the posts about Eamon to last, at most, another month, and possibly significantly less depending on how much I manage to get done over the holidays. After Eamon, I'll be going back in time a bit more in my chronological crawl... I said before that Eamon was the first game creation system I could find, but while that remains more or less true, now that I've added level editors to my purview, I have found some earlier games with level editors. Specifically, so far the earliest game I could find with a level editor was a strategy game called Starfleet Orion, released way back in December 1978. Like most level editors, I don't expect Starfleet Orion to justify more than one blog post, though; in fact, it will probably inaugurate a new label, "One and Done", for level editors that are covered completely in a single post. This will be followed by posts on a number of other programs that'll very likely also be "One and Done"s, such as Starfleet Orion's sequel Invasion Orion, a Magnavox Odyssey2 cartridge called Computer Intro! intended to introduce users to assembly-language programming (which admittedly makes its inclusion as a game-creation program a bit iffy, but the majority of the complete programs included seem to have been games, so it's arguable that that's what it was primarily geared toward), and a very rudimentary racing game called Dot Racer, before we finally get to another game creation system that may justify a slightly more in-depth analysis, 1981's Dungeon Definition Language.

Some of what we've got to look forward to.  (Images from eBay, the Digital Press "Room of Doom", AtariGuide, and, er, a screenshot collection maintained by an Italian C64 fan.)
Depending on how much progress I make with my 001 game in the meantime, as well as whether I run into anything interesting and unexpected worth blogging about, there may or may not be another 001 post mixed in there at some point. One likely candidate is a second post about mapping in 001, as I realized that the previous post about mapping dealt with creating individual maps, but not with how the maps are connected together—that'll probably be worth another post on its own.

So... sorry to not have been able to make a more substantive blog post this week, due to other urgent matters that have been occupying my time and attention, but I hope this taste of things to come has been... well, has been better than not posting at all, anyway. In any case, there'll be much more coming after the ninth.

Saturday, November 30, 2013

001 - Mapping

We've seen a little about the resources that are available in 001—and some minor issues with them. Now it's time to get more into what we can do with them. Specifically, let's get into the mapping.

A nice forested inlet, but beware of snakes.
Mapping can be time-consuming, but it may be my favorite part of creating a game. I enjoy building the game world, putting in secrets to find and scenery to see, trying to make an interesting and evocative environment. Of course, how much I enjoy mapping depends to some degree on how the mapping is implemented in a particular program.
In 001, the basic functionality of the mapping is similar to that of many similar tile-based game creation programs. Click on a particular tile from a menu to select it, and then click on the map to lay down that tile. I'll have to get more into my chronological crawl before I can say with any level of confidence what was the first game creation system to do this, but it dates at least back to 1984's Adventure Construction Set, making it about three decades old, and many other game creation systems have followed suit since. It's become pretty much the standard way for such systems to work, in fact, common to full-fledged game creation systems, to level editors, and even to map creation utility Tiled.

A partly finished map I happened to have in Tiled for a game that may never be done.

Of course, there's a reason it's become so widespread; all tile-based game creation systems have similar goals they're trying to fill, after all, and this seems the most natural way to do it. Certainly other methods are possible; the Lode Runner level editor, for instance, had hotkeys to select the next tile to be placed, with the legend arranged at the bottom of the screen. While this may work when there are only ten different tiles, however, it would be clearly unworkable for the dozens or hundreds of tiles in more detailed systems. Still other methods are conceivable, but perhaps none as direct or as intuitive as the tile-menu method. It's not even necessarily the case that the makers of the different systems have copied each other... the basic mechanism is simple enough that it could easily have been reinvented independently multiple times.

However, there are, of course, variations in how the system is implemented. ACS took the user to a different screen for the tile selection, as more recently did DinkEdit, while Tiled and Knytt Stories, for example, have the tiles arrayed at the bottom left. 001, like RPG Maker, has the menu over to the side, and perhaps goes RPG Maker one better by having numerous submenus the tiles can be selected from.

This would be the "Furniture 2" tileset
A more significant variation than the mere placement of the menus is that many game creation systems have implemented methods of laying down more than one tile at once. 001 is not remiss in this regard, having tools for laying down tiles in lines or in hollow or filled rectangles or ellipses (the tooltip names "Circle" and "Filled Circle" notwithstanding), and for floodfilling areas with a given tile. As with RPG Maker, it's also possible to select a block of adjacent tiles from the menu and lay them down at once, handy for large features that take up multiple tiles. Tiles can also be flipped vertically or horizontally, which is nice for adding a bit of variation to a map. And the basic ground tiles have an "Terraformation" feature to make them merge elegantly into other such tiles. Again, this is something that many other game creation programs have done, including RPG Maker (where it's called "Autotile"), Blades of Exile, and, with 3D tiles, Neverwinter Nights. But it's a nice feature to have... when it works.

Unfortunately, in 001, it doesn't always work. It's fine as long as tiles of no more than two different types meet at one corner, but a corner with three (or four) different tiles ends up with ugly discontinuities. It might seem, then, that one should just avoid having more than two different types of tile meeting at a corner, but there are times when it's really desirable to do so—for instance, as it is, you can't have a river or pond bordered by more than one kind of tile without running into problems; if the river's shore is all (one kind of) grass or all (one kind of) dirt, you're fine, but you can't mix them without unsightly sharp boundaries.

How many bad transitions between tiles can you see?  (Okay, I don't recommend you actually count them.)

On the one hand, yes, one could argue that it would be unrealistic to expect tileset creators to anticipate every possible combination of three or four tiles meeting at a corner. By my (quick and possibly inaccurate) calculation, not counting rotations or reflections, for seven different ground tiles there would be 406 different corner possibilities. (And honestly, maybe we should count rotations and reflections, since they may require separate tiles. That bumps up the number to a hefty 2,401.) Still, there are ways to implement more boundary possibilities without manually creating each necessary tile. At least some versions of RPG Maker, for instance, do something like keeping one tile as a baseline and overlaying other autotiles over that, so that if they meet at a corner there'll be a smooth fringe of the baseline tile between them rather than a straight boundary. That means all it needs to do is ensure a smooth transition between each autotile type and the baseline, rather than any two arbitrary autotiles. Furthermore, both Blades of Exile and recent versions of RPG Maker allow the user to override the autotiling if desired and pick an arbitrary tile out of all the possible autotile possibilities, a feature that can come in handy if the user wants to have a particular boundary work differently in one place from how it usually does.

Actually, for a moment I thought there may be a feature like RPG Maker's autotile overlay method in 001 after all. The "Tile Transformation" window (accessed by selecting "Tile-Sets" from the "Resources" menu, choosing on a tile with "Terraformation Graphics" set, and and then double-clicking one of said graphics) includes a "Style" dropdown, with the options "Absolute", "Overlay Inside", and "Overlay Outside". However, these selections don't seem to make 001's Terraformation work like RPG Maker's autotiling after all. In fact, as far as I can tell, these selections don't do anything at all. Nor is there any hint as to their function in the documentation, and this time even a search on the 001 Forum was of little help. I'm sure they do something, but figuring out exactly what will require further experimentation (and/or posting on the 001 Forum to ask, I suppose), and that can wait till I get to making my own tilesets.
Yeah, I'll figure out how this window works later.

Incidentally, though, and this isn't a complaint unique to 001, why hasn't anyone (at least in any game creation program I've looked at so far) implemented a sort of autotiling/terraformation that works with cliffs? Both RPG Maker and 001 have cliff tiles, and in both programs the cliff tiles have to be placed one by one, making them rather tedious to map. Surely it would be possible to streamline this process.

As it turns out, though, even aside from the Terraformation issue, cliff tiles were to play a major role in my learning about 001's mapping features. I thought a more varied terrain with different elevations would be more interesting than having the maps all flat, so I made rather liberal use of cliffs when laying out my maps. (And, incidentally, given the combination of rivers and cliffs on my map, I've wished the tileset included waterfall tiles. For now, I'm just putting all the rivers at "sea level", but I may decide to add some waterfall tiles when it comes to customizing the tileset. But anyway, that's a resource issue, not a tileset issue.) But at one point laying out the map to the starting area of my game, I realized I'd left rather too little room for an inn at the bottom of the map south of some cliffs, and that if I wanted to make more space to enlarge the inn the only way to do it would be to move the cliffs north. And then I realized to my dismay that the only way to do this would be to reconstruct the cliffs there, tile by tile. There was no apparent way of selecting parts of the map and copying and pasting them. This is a feature that some other game creation programs do have (RPG Maker, for instance, and I know I keep mentioning RPG Maker but it's because it's one of the best known and most used game creation programs so it's a good baseline for comparison), and it's one that's sorely missed here; it would have saved me a lot of work.

The old inn, before the cliff was moved.  Looks cramped, doesn't it?
I say there was no apparent way of selecting parts of the map because it's hard to know just what features 001 does have, given its horribly meager documentation. There's an odd glitch with the documentation from the Help menu in that the initial Home page that first comes up is apparently copied from the front page of the online 001 wiki—but the links weren't updated to go to the proper Help pages, so none of the links from the main Help page work. Selecting the appropriate topic from the menu on the left, however, works just fine.

This does not strike me as particularly helpful.

I praised 001 before for having its documentation available in a Help file in the program, but the truth us that I really prefer to refer to help documents in PDF format. I know not everyone may share that preference, though, and maybe the ideal situation would be to have both an in-program help menu and PDF documentation, and having online help in addition to both of these certainly wouldn't hurt. In 001's case, though, the format of the documentation isn't so much of an issue as its complete inadequacy; there's just not much there. The documentation gives a very brief summary of each tool and menu option, but it explains nothing in depth, and there are many program features that are explained very poorly, or not at all. There are other support resources available, most notably the aforementioned 001 forums, but overall 001 just is not a well documented program. Which is a pity, because I've found some very interesting features here, and there may be more possibilities to the program that I'm not yet seeing.

(Should I have made a separate post about the documentation? Possibly. I don't know that I have enough to say about to warrant a full post, though; I think what I've said above will do for now.)

With regard to the copying and pasting issue, I honestly don't think that's a documentation issue, though. If there were a way of selecting multiple tiles on the map, I would expect it to be among the buttons to the right of the tile menu, and it just doesn't seem to be there, or anywhere else I looked. The second issue that I discovered through the cliffs, however, is a different matter; it's a feature that the game does have that I didn't know it had, or at least didn't really understand, and it definitely should have been better documented. I refer, now, to layers.

That such a thing as layers even exists in the game is not immediately obvious. There is, however, a button in the Display toolbar with tooltip text of "Visualize Layers". Furthermore, the "View" menu includes the options "Move Up Layer" and "Move Down Layer". So... apparently it's possible to lay tiles on multiple layers. But what do the layers actually do?

001 isn't the only tile-based game creation system to have multiple layers, of course. RPG Maker does, too, as does Tiled, for that matter. And so my first assumption, naturally, was that 001's layers worked the same as RPG Maker's. In RPG Maker, layers are essentially just a way of putting more than one tile in one space. Now, in 001, there are already separate "Floors", "Lower Objects", and "Upper Objects" that can share spaces, which already fulfills much of the purpose of layers in RPG Maker, but I thought maybe with layers I could put, say, one "Lower Object" in front of another, in case I wanted, for example, one cliff behind another. I've done similar things with the layers of RPG Maker in the past.
All the brighter areas are in the middle layer (of three).

A bit of playing around with layers in 001, though, appeared to indicate that this wasn't what they were for here at all. Objects on higher layers seemed to have odd effects on blocking movement, and cast strangely displaced shadows. When I figured out what was really going on, though, everything fell into place. Unlike the layers of an RPG Maker map, the layers of a map in 001 really were vertically displaced in the game's physics. In fact, it's possible to jump from a lower to a higher layer, or to fall from a higher to a lower.

At first glance these three bushes look like they're arranged in a horizontal line, but look closely at the shadows.

The Map Properties window (right-click on a particular map in the Maps menu in the lower left, then select "Properties..." from the ensuing pop-up menu) has settings for not only the Width and Height of the map, but also its Depth—number of layers. Most objects are placed on only one layer, but walls are an exception; a wall exists in several layers at once. As a matter of fact, it's possible to control how high the walls are—and thus how many layers they take up—through a slider control next to the wall tile menu. The default is two, but the walls can go up to ten layers high—assuming the depth of the map they're on is set high enough to accommodate them. (This brings up, again, the question of why there's no such Terraformation of the cliff tiles; surely they could have been implemented in a similar way to the walls?)

I don't plan on leaving these walls in the final version of my game...

This fit in, too, with something else I'd been wondering about. Another of the settings in the Map Properties window is "View", which is set by default to "Standard 45°". I hadn't been sure what this meant, but now it made sense. With this setting, the maps are seen in a sort of a birds'-eye view orthographic projection, with the projection lines directed downward at an angle of 45° and perpendicular to the direction of one edge of the tiles. (Is there a name for this projection? (It's not isometric; that involves the projections of the tile edges being at 120° angles, like in Sid Meier's Civilization II or III, SimCity 2000,StarCraft, Roller Coaster Tycoon, or the Avernum games, among many others.) I couldn't find one, but there should be; it's a very common projection in computer games, used in many JRPGs.) In this setting, objects on an upper layer are displaced one tile upward, appearing visually directly before objects just to the "north" on the next layer down. In contrast, in "Top" mode, objects on different layers are simply directly superimposed—though this mode is clearly not intended for use with the default "Action-RPG (Pro)" tileset. There are four other view modes, but "Front" is presumably intended primarily for platformers, and "Side", "3D Isometric", and "3D Perspective" are premium features available only for subscribers. (I haven't ruled out becoming a subscriber—heck, I probably eventually will—but I'm not currently.)

Top and bottom: The same section of the map in "Standard 45°" and "Top" views, respectively.

It's especially unfortunate that this feature is so poorly documented (in fact, pretty much undocumented... there are a few vague references to layers in the documentation, but none that come anywhere close to explaining how they work), because this is actually a really neat feature, and in fact so far of all 001's features I've found it's the one that most sets it apart from other game creation systems. It's possible to sort of fake having multiple layers on RPG Maker and similar programs, but it's not really built into the system, and even having something as simple as a bridge the player can go over or under involves multiple Events and some messy kludgework. Actually having multiple physical layers to the map opens up some great possibilities.

Each of those squares is an "Event", and all those Events are there just so that the player can walk both over and behind cliffs in two spots.

I really wish, though, that I'd discovered this feature before putting so many cliffs in my maps... because, of course, the cliffs also should go on multiple layers, and, not knowing how layers worked when I first put them there, I now have to redo them all. Yeah, so those cliffs in the starting map that I laboriously rebuilt so I could move them farther north and make room for the inn? Well, I'm going to have to laboriously rebuild them again so I can put them properly on different layers. For that matter, since the inn itself is on an elevated area, I'm going to have to rebuild it too. Along with everything else that I put up "above" any cliffs or elevation changes. Aargh.

I kinda like this plateau, but it's going to have to be completely redone.  Dagnabbit.

It wouldn't be quite so bad—it would still be bad, but not quite so bad—if moving between layers were quicker. As it is, though, the only way to move between layers is the rather inconvenient method of selecting "Move Up Layer" or "Move Down Layer" from the View menu. At least, that's the only way I know of; maybe there are hotkeys for it, but if so they're undocumented, like so much else about the program. If there aren'thotkeys for it, there really, really should be. Hotkeys (especially for moving between layers!) rank up with selecting, copying, and pasting parts of the map as one of the features so far that most stand out as being missing from this system.

The map of the starting area so far—there's lots still to be done, but progress is being made.

Anyway, I think this may be the last post on 001 for a while. Not that I won't continue working with it, but what I've got ahead of me now is a lot of mapping (and re-mapping, given the layer issue) that isn't likely to generate anything new to post about. I will be posting again about 001, of course, when I get done with the mapping for now and am ready to move on to the next stage, or when I run into something else concerning the mapping that's worth writing about, but for now expect the next few posts to deal with Eamon again. See you... hopefully before next Saturday.

Saturday, November 23, 2013

Game Makers vs. Level Editors

Well, heck, I guess I finally broke my string of one post a week every Saturday, but not in the way I intended. Yeah, sorry I missed last week; I was out of the country last weekend, and while I hoped to get the post up before I left, I... didn't quite. (I came close, though; actually, nearly this entire post—this paragraph obviously excluded—was written well in advance; I just never quite got to posting it. Well, and to getting the screenshots for it, which honestly took way longer than writing the post itself...) I hope this will be the only time more than a week passes between posts, but I can't guarantee it. And, sadly, even after the long delay, this won't be a big meaty post about either Eamon or 001, either. Those are coming, of course, but first I have to post about another slight change in the blog's policies.

I've said that I haven't had much time lately for the blog except on Saturdays, but that's not entirely true. Honestly, part of the reason my blog posts have been so infrequent is because much of the time I have been devoting to the blog has been spent not working with the game creation programs but compiling that chronological list of game creation programs I'm still getting together. It's not easy, and not made any easier by the fact that many of the programs are shareware or freeware distributed on websites that either are long defunct or have preserved no information on their history. Nor did it get any easier when I decided that, rather than just the year, I wanted to try to pin down the dates to the day, if possible, or at least the month, so I could put them in as close a resemblance to actual chronological order as I could achieve. I've been spending untold hours delving the depths of the Wayback Machine and old Usenet announcement posts. (And found in the process, incidentally, that the release dates given for shareware/freeware programs on sites like MobyGames are often off by a year or more. Blargh.) Also slowing down the procedure is that in the process of hunting down information on programs on my list, I end up running across webpages I was previously unaware of listing more programs to add to my list, so the list keeps on growing. I'm up to over three hundred programs now, and counting.

A partial glimpse of the spreadsheet I'm using for the list.  I could probably be doing a slightly better job of organization.

I'm pretty sure at this point I've spent much more time compiling the chronological list than I actually have using the game creation programs, let alone writing the blog posts about them. This is not because I enjoy compiling the list. On the contrary; this is the least fun, most laborious part of this blog. But for that very reason, it's something I want to get over with. (And once I do finally get the list ready to post, I'll have that much more time for blogging about the systems.)

By the way, for what it's worth, it turns out 001, the "current" game system I'm working with (in parallel to Eamon, the first system chronologically), is older than I thought; the first release version came out in August 2005. I guess it still qualifies as current, though, since it's still under development. (I don't know how different the current version is to the original release... I'm guessing it's probably significantly improved, but I don't think 001 is as seminal to the evolution of game creation systems in general that I'm going to feel obligated to look at different stages in its development.)

As I've been working on the list, though, I've had to grapple with one issue that I kind of addressed when I first laid out my ground rules, but that I'm increasingly uncertain I addressed satisfactorily. This being the difference between a game creation program and a level editor. There are some programs that are clearly not level editors, in that they either don't come with any games, or, even if they do, the editor came first and the accompanying game is overtly intended as a demonstration of its capabilities rather than an independent release. 001 is an example of this, as are RPG Maker, Adventure Game Studio, and Adventure Construction Set (Rivers of Light notwithstanding). And then there are level editors that clearly can't be considered independent game creators, like the level editors that came with, say, StarCraft, or Lode Runner, or The Incredible Machine. But then there's a big fuzzy gray area in between, of editors that may be intended to work with a particular game, but are flexible enough to allow large levels of customization and possibly qualify as game creation programs in their own right. And I've got some of those on my list. Blades of Exile and Blades of Avernum. Exult Studio. The Bards Tale Construction Set. Heck, there's DinkEdit, mentioned in the last post. I tried to set forth some objective criteria to decide whether or not a particular program met the qualifications, but they were never as clear-cut as I tried to convince myself there were. When a commenter suggested that I add the Elder Scrolls Construction Set to the list, I readily agreed; I'd been thinking it was a borderline case anyway. But truth be told, that just shifted the hairline border slightly, and created new borderline cases. Or really, even that's an oversimplification, since the programs were never really in a strict linear continuum anyway. Heck, in my ground rules I explicitly list the Dungeon Siege Toolkit as an example of a level editor that doesn't qualify as a game creation program... but really, given its userbase and what's been done with it, a very good argument can be made that it should qualify too.

Some of the resources available at

Then, too, there's the argument that level editors could have contributed to the development of game creation programs, so if I really want to explore that development, I ought to look at them. After all, even a very specialized level editor is doing some of the same things as a game creation program, just on a smaller scale, and it may very well introduce an interesting new way of doing things. Looking at just game creation programs obviously not tied to any existing games, and ignoring level editors that are so tied, may not give a big picture.

On the other hand, there's the counterargument that adding every game that ever had a level editor may bloat my list beyond manageability. Nowadays, level editors have become a common feature, and even obscure Flash games on Newgrounds and similar sites often have level editors of their own. As desireable as it may be from some standpoints to look at level editors as well as dedicated game creation programs, in terms of sheer volume it may be unrealistic.

It may be time for a paradigm shift.  (Sorry.)

And, of course, even more so than the systems already on my list, many level editors come with commercial games that aren't readily available, and may not be cheaply acquirable. As I've mentioned before, I'm not exactly rich. I'm not even approximately rich.

On consideration, though, I think the arguments in favor of including level editors are stronger than the counterarguments. In my concurrent modern games, I'll stick with the less questionable game creation systems; I'll only deal with level editors in my chronological trek. And there, I won't have to worry about too many near the beginning; level editors may be commonplace now, but I think they were far less so in the 80s and early 90s. The financial argument won't apply as strongly to those older games, either, given that most of them are readily available online (albeit, of course, er, not entirely legally). The real problems with including level editors will only crop up once my chronological journey starts approaching more recent years. And it'll be a long time before that happens. I'll cross that bridge when I come to it.

And hopefully won't end up just walking through it. (If you haven't read the previous post, that reference won't make sense to you... sorry.)

Oh, another thing... the time it will take to blog about a dedicated level editor should be relatively short, too. I expect at least another four posts about (the current incarnation of) Eamon before I'm done with it. On 001, probably dozens. But something like the Boulder Dash Construction Kit, heck, I'm pretty sure I'll be able to knock out everything I have to say about that in one post.

Do not expect a ten-thousand-word disquisition about this.

So, yeah, I guess I'll be adding level editors to the chronological list, too. Which I guess is going to make it take me even more time to compile. But I'll keep plugging away, and I'll get this dang thing done eventually.

Saturday, November 9, 2013

001 - Off To A Bumpy Start

Well, I still seem to be stuck in my rut of Saturday updates. I swear I'll make a real effort this week to get an update up on some earlier day and not cut things so close with my goal of letting no more than a week pass between updates. (I guess technically I missed that goal this week by a few hours, but, uh, we can round to the nearest day, right?*)

Anyway, we've seen a little of what 001 has to offer, and now it's time to actually start making the game. I admit I haven't planned out every detail of the game I want to make with it, but I have enough of a concept to get started. As I mentioned in a previous post, given the mixture of fantasy and modern elements in the "Action / RPG (Pro)" template, I decided to make a game that involves travel between several different worlds. Some of those worlds will require me to make my own resources, but I'll tackle that later on. The starting world will be a more or less typical fantasy world, for which I'll be able to use mostly extant resources, so I'll focus on that first.

Of course, preparatory to actually doing anything on the computer, I roughed out a map for the game, or at least for the exterior regions of the gameworld. (Dungeons, or their equivalents, will come later.) Here's what I've got so far:

Don't worry if you don't know what all the marks on the map signify.  I do.

It's not detailed (to put it mildly), but it's enough to let me get started. The plan is for there to be eight worlds, and for each world to comprise a grid of eight by eight maps, though obstacles may prevent the player from walking directly between adjacent maps. (The starting map will, in fact, have an initially impassable ocean to the north; the player will eventually get to the areas to the north by other means.) Two of the worlds I haven't even started laying out yet, and some others are incomplete, but that's okay; those are all worlds that I'll need custom resources for anyway, so it'll be a while before I start mapping them in the program. The starting world is the one in the upper left. And the starting area in that world is in row 5, column 6. So that's where I started mapping.

Here's an early stage of the map for this region:

If you think the inn seems cramped, I agree... but more on that in the next post.

So far, I put in some water, some trees, some changes in elevation, a shop, an inn, and a bit of scenery. This map is, incidentally, at 25% scale, and one of the nice features of this program is that it does allow you to view the map at various scales, from 25% to 200%: the map you see here is scaled within the 001 editor, not externally with an image editing program. Again, this isn't unique to 001; it's a feature I've certainly seen before in other game creation programs; but it's still a nice feature to have. Anyway, though, before going too much farther, I decided to test out what I'd done so far, to make sure everything was working fine. The editor has not one but two buttons to test the game in progress, one labeled "Play" and one labeled "Test". Both allow the user to choose where on the map he wants to start playing; the only difference is that "Test" also allows the user to specify some scripting to run before the game starts.

I'm sure I'll be delving more into this screen when I get into scripting in the system.

Anyway, when I tried out my new map, here's what I saw:

Make your own "pier pressure" joke.

(Incidentally, the motion is much smoother in the game than it is in this .gif; I couldn't find a way to record video from the screen at a decent frame rate. The video above was recorded with CamStudio, which seems to be well reviewed, but I couldn't get it to work as well as I want to. If anyone more experienced than I in such matters has any suggestions, please let me know (though I concede it's entirely possible that the problem is with my computer and not with the software).)

There are two notable issues visible in this video. Well, three if you count the red circle in the upper left, but I honestly have no idea what that's about. It's always there, in that same position on the screen, whenever I test the game (though not when I test the demo RPG that came with the system). It may be due to some script included in the default template; I'll look into it more when I get into scripting. I can't find anything in the documentation that indicates what it might be, though the documentation is rather scanty anyway. On the plus side, though, the documentation is included as a Help file with the program rather than being only available as a webpage. (I'm okay with documentation being in PDF format instead of Windows Help format, but I hate it when the only documentation available is online. And I especially hate it when the program doesn't indicate this, and clicking on "Help" in the program menu takes me to a webpage without warning. Grrr.) Some online resources are available to supplement the in-game help, however, including a wiki and a forum.

And in fact by searching the forum I've just now solved the mystery of the red circle, or the "Big Red Ball Thing", as it was called by the person who started a thread about it. Apparently that's the PC's health bar (as implemented by default in the template). Good to know, though it would have been nice to have something about this in the game's actual documentation. In fact, come to think of it, there's really no documentation of the template at all (unless you count a tutorial that doesn't address such details). Still, when I got to looking at the interfaces, I'm sure I would have found out what the red circle was then even if I hadn't found it just now.

So, yeah, okay, forget the red circle. There are two things in this video of more immediate concern. The more notable of the two is probably the way the PC walks right through the pier and into the water, but I'll deal with that in a moment. First, I want to talk about the fish on the right side of the screen. A fish is a nice decorative thing to put into a watery area in the game, sure, but in this case there are two problems with it. The more egregious problem is that for two frames, the fish decides that it would rather be a part of the pier. As it turns out, this is an easy fix; it's just due to the way the fish animation was defined in the tileset. A couple of right-clicks are sufficient to remove those spurious pier frames and restore the fish to pure piscinity. The very fact that it is such an easy fix, though, makes it all the more inexcusable that the glitch exists in the template as released... I get the impression that the creators of 001 really needed to do more beta testing.

Even after convincing the fish not to aspire to pierdom, however, there remains another, more subtle problem. The fact that the fish is seen entering from the right side of the tile and leaving on the left means that if it's put in the middle of the water it seems to materialize from nowhere, and disappear into nowhere as it leaves the tile. Unless one is content to populate one's world with fish capable of passing through invisible portals, this, unfortunately, makes the fish tile fairly useless. I guess if I'm going to meet my goal of using every tile in the provided resources, I'm going to have to find a place to put it, but the only possibility I can think of is putting it in a narrow gap between two foreground elements that obscure the left and right sides of the tile. That, or making an endless conga line of fish stretching all the way across the screen.

Actually, I guess the timing isn't quite right for the fish conga line to work after all... not that I really wanted to do this anyway.

There's one more note I'd like to mention about the fish, before moving on. A decorative fish as an element of a tileset may seem like an unusual choice, but 001 isn't the first game to include it. A similar fish was included in the tileset of DinkEdit, an editor released in 1998 for the indie CRPG Dink Smallwood. (DinkEdit's on my list, but it's likely to be a long time till I get to it; there are a lot of systems between Eamon and it.) Unlike the fish in 001, the animation for the fish in DinkEdit actually includes its jumping out of the water and splashing back into it, making it rather more practical for actual use.

I spent way too much time looking for the old adventure I started working on with DinkEdit years ago, just so I could get this shot.  I hope it was worth it.

The fish isn't the only similarity between the two systems; there are a few other little things about 001 that reminded me of DinkEdit as well, such as the way the cliffs looked, the way multiple tiles can be selected from a tileset and placed as a block (though admittedly that's also done in RPGMaker), and the way scripts were attached to individual actors. Certainly none of these is a smoking gun proving that 001 took inspiration from DinkEdit, but cumulatively they do suggest the possibility, and given the age of DinkEdit and the fact it had a decent-size fan base it's not inconceivable. It's also possible, though, of course, that the similarities are coincidental. For that matter, it's certainly possible that many of the common features of 001 and DinkEdit came from a third game or system that I'm not yet familiar with.

Incidentally, the "Action / RPG (MSPaint)" tilesets also include a fish, but unlike the one in the "Pro" template—but like the one in DinkEdit—this one is actually seen jumping out of and landing back in the water. (The animation isn't set up in the template, though; all the frames are there, but the user has to make the animation himself. Still, this only takes a second or two.) This makes at least one respect in which the "MSPaint" template is superior to the "Pro". (Actually, there are others; the "MSPaint" template includes a greater variety of indoor floor tiles, for instance. Hmm.)

Though the corners of the shoreline have another ugly animation glitch.  Dagnabbit.
All right, five paragraphs and three and a half animated gifs is more than enough space to devote to a single fish tile. Let's get back to that walking-through-the-pier issue, because that one's a bit more serious. It took me a while to figure out just what's going on here, but there are two separate issues involved.

One is the fact that the PC can walk into water. I remarked on this before on trying out the demo Action RPG, and thought then it was a bug. Turns out it isn't; allowing the PC to walk into water is apparently intended behavior, stemming, I suppose, from a setting called "Submersion Tiles" on the tileset screen. Presumably changing the value of this setting alters the maximum depth to which the PC can be submerged, though I haven't experimented with it to see the results for sure. (I guess I'll do that when I get to making custom tilesets.) The fact that the PC can get stuck in the water I'm pretty sure is a bug, of course.

When I make my own tilesets, think of all the horrible substances I'll be able to submerge the PC in!
That bug aside, I have mixed feelings about letting the PC wade through water like that. Actually, I guess overall I like it; it's a nice touch you don't see too often in action RPGs, in most of which water is simply an insurmountable obstacle unless the PC has a boat (as I assumed it was supposed to be here when I played the demo RPG). I guess my only reservation—aside from the unfortunate bug that allows wading PCs to get stuck—comes from the fact that water does make such a convenient obstacle; in fact, like I mentioned above, in planning out the map for my game before I realized the PC could wade through water I'd intended the water to initially block the PC from going north from the starting map. I guess I can put some invisible blocks preventing the PC from wading too far in the water, both preserving this feature on the map and preventing the PC from going in deep enough to fall victim to the bug and get stuck.

That doesn't explain the bit about walking through the pier, though. As it turns out, that has a simple explanation: the pier isn't actually a "Ground" tile, but a "Lower Object" tile intangible to the PC. The demo RPG had used the "pier" graphic as a bridge and it had seemed to work well enough, but on examination that was only because it was so short; the river was narrow enough at that point that the PC didn't sink into it. A longer bridge suffered from the same issue as the piers.

So I guess this was... a bridge too far.  (Hey, I'm trying to come up with a caption for each image, but they can't all be gems.)

Like the fish animation, this turned out to be simple enough to fix... that is, it took me a long time to figure out how to fix it, but once I did it was very simple to do. All I had to do was edit the tileset and change the "Collision" setting of the pier tiles from "None" to "Flat (32x32x0)". Voilà... now the PC walks on piers and bridges instead of through them, and all is right with the world. Though, again, this is something that really should have been fixed before the template was released.

And the PC will no longer walk amid the pier... or should I say, pier-amid.  (Okay, that caption's even worse than the last one.)
It may seem like I'm complaining a lot, but honestly there's a lot to like about this system. Unfortunately, it has a lot of problems. Like I said, it seems the creators really should have run it by more beta testers before releasing it. (I was about to add that at least for freeware it was understandable that they didn't take too much time for beta testing, but then I remembered that 001 isn't freeware; they do charge money for the pro version.  Yeah, they really should have done more testing.)  Still, I think it should be possible to make a good game with 001.

I'd planned on getting more into the actual mapping in this post, but I think it's become long enough I probably ought to save that for the next one.  I have quite a bit to say about 001's mapping capabilities; there's one very nice but very poorly documented feature, and two features I think the system is sorely missing. But all that'll wait till next time... which I really hope will be before next Saturday.

Saturday, November 2, 2013

Eamon - Resources

Okay, I seem to have fallen into a rhythm of making a post every Saturday. Technically I guess I haven't broken my goal of making at least a post a week, but this is not what I had in mind. It's just that I've been very busy lately, and Saturdays have been about the only days I had enough free time to make a post.

Which isn't to say that's the only day I've been doing anything related to the blog. On the contrary, I've spent quite a bit of time this week playing other Eamon adventures to try to get a feel for the system, and planning out the adventure I'm going to create with it. And as I've played other adventures, I've found that several of the details of my previous post are actually incorrect... but more on that next post. For now, I want to get into Eamon's resources.

Speaking of "resources" when it comes to Eamon may seem a bit odd. It doesn't really come with any resources, in the sense I've been using the term in other posts; there are no preset monsters, locations, or other ingredients to put into a created adventure. Of course, it's possible to copy such items from other adventures, but that's true for many systems. However, what Eamon does have is a specific world it's set in. And while I didn't actually discuss settings when in my ground rules when I mentioned resources (maybe I should edit that post to put that in), I also intend, if a game creation system has a particular setting in mind, to create a game in that setting.

In case you were wondering, the rest of the last sentence is "and Darth Vader!"  As we'll very soon see, it's not wrong.

There's a little description of the world of Eamon in the Player's Manual, and a handful of adventures have established a few more details. The most centralized collection of information about the world is in the Eamon wiki. Essentially, Eamon is a planet in the dead center of the Milky Way (though according to the Wiki page on at least one occasion Eamon's creator contradicted himself and placed it at the center of another galaxy), orbited by three moons. In many ways, it seems to be a typical quasi-medieval fantasy world, but because of "the shifting pull of all these great bodies" of the galaxy moving around Eamon, the laws of science work differently there, and time and space shift and warp.

This last bit was clearly put in as an excuse for Eamon adventures that include elements not typically found in fantasy. Indeed, many Eamon adventures take the player off the world of Eamon entirely, pulling him into some other world and then dropping him back at the end. That this was fully intended by Eamon's creator, Donald Brown, is amply demonstrated by the existence of Eamon Adventure #6, The Death Star, written by Donald Brown himself. In this adventure, the PC is pulled through a "reality shift" into the Star Wars universe, starting on the Millennium Falcon and then making his way through the Death Star to possibly face Darth Vader himself (as well as a rather out-of-place kzin from Larry Niven's "Known Space"). Adventure #26 has the PC meeting the Fantastic Four; #28 brings him to the Tower of London on Earth, and #38 returns him to the Star Wars universe for a pastiche of The Empire Strikes Back.

I'm really not sure how this whole "new 'memories'" thing is supposed to work...
So clearly sticking to the established planet of Eamon is by no means a requirement for an Eamon adventure. Still, following established settings is a rule I plan to try to go by in this blog, so my adventure will be set there, even if all the old adventures weren't. I've already given some thought to what I can do that's interesting with the relatively little that's been defined about the world of Eamon, and my first idea was to explore the planet's immediate cosmological surroundings a bit more, in an adventure I was considering calling "The Observatory". This, however, was before I found that the earliest version of the Dungeon Design Diskette I had access to only supported up to 100 rooms; what I had in mind was a bit more extensive than that, and I didn't want to limit it that far. I then came up with another idea set in Eamon's polar regions that would address some of the history of the POWER spell and the reason for its random effects. (That adventure I'd considered calling "Icecap".) But then when I posted about the shortage of adventures for Eamon that were suitable for characters straight out of the Beginners Cave without cheating, I figured that if I was going to complain about that, I ought to do something about it, so I'm going to make an adventure that gives inexperienced characters a good chance at getting more experience and better weapons in an interesting way... and even provides a way for characters to increase their attributes, though that won't be easy. (It won't be easy for the characters, I mean, not that it won't be easy to program in.) It may not contribute to fleshing out the world quite as much as the other two ideas I had, maybe, but I think it could be a worthwhile addition to the collection of Eamon adventures. And as I said, I'm going to be revisiting Eamon later in the blog as I get to the time of newer versions, so it's not like I can't use my other two ideas later on...

Okay, this was a short post, I know. I'm not sure yet whether the next post will be about Eamon or about 001, but either way it's going to be substantially longer than this one. And I hope it'll be up before next Saturday. Anyway, see you then!

Saturday, October 26, 2013

Eamon - First Impressions

Eamon: First Impression: A very early CRPG/text adventure hybrid system that's highly customizable if you're okay with doing some programming

Except for this title screen, it's an all-text game.  This is as exciting as the screenshots are going to get in this post.
So to begin our foray through game creation programs of the past, we'll take a look at Eamon. Inspired, like so many other computer games, largely by Dungeons & Dragons, Eamon is a text-based computer role-playing game in which the player can take characters through various scenarios. The character can accumulate gold and weapons and armor and keep them between scenarios; adjustments to attributes also can carry between scenarios, though they're much rarer. The interface in Eamon resembles a (somewhat primitive) text adventure; the player can type in commands like "NORTH" and "GET DIAMONDS" and "ATTACK GORILLA". What makes Eamon a suitable subject for this blog, of course, is the fact that utilities were provided for users to create their own scenarios they could then share and distribute, and that other players could send their characters through. This makes Eamon the earliest game creation system I could find... apparently.
"ATTACK GORILLA" wasn't just a random example phrase.

Actually, I'm not entirely sure just how early Eamon is. Wikipedia pegs its release date as 1980, but other sources place it earlier. A timeline on the Eamon wiki places its release in late 1979. According to an article by the Digital Antiquarian, John Nelson, a person instrumental in Eamon's development, even stated once that it was already out there and playable in 1978, though based on other evidence the Antiquarian ultimately concludes that Nelson had misremembered. As far as the chronology of the game creation systems I've found, which of these dates is correct doesn't really matter, though the Digital Antiquarian's arguments are persuasive enough that I'm leaning strongly toward the late 1979 date seeming most credible. Even 1980, the latest of these years, would place it previous to any other system on my list; the next earliest system I was able to find, the similarly themed Dungeon Definition Language, didn't apparently come out till 1981 (so I guess that's the one we'll be looking at next, if I can find some extant implementation of it, which seems dubious... its successor the Adventure Definition Language is readily available, but wasn't released till 1987*). And of course any of those years would place it surprisingly early in the history of computer role-playing or adventure games. Hackers had been creating role-playing games on mainframes since the mid-seventies, but Akalabeth: World of Doom and Dunjonquest: Temple of Apshai, the first two role-playing games for the desktop computer, were both released in 1979 (maybe; as Matt Barton mentions in his History of Computer Role-Playing Games, the labels of the first known copies seem to indicate that, Lord British's reminiscences notwithstanding, Akalabeth may not have actually seen release until 1980). It isn't Akalabeth or Apshai that Eamon most resembles among contemporary games, however; it's Zork.
Okay, here I got really lucky.

In case there's anyone unfamiliar with this classic game, Zork was the first commercial product released by Infocom, a company that established itself as the final word in text adventure games, before falling first to bad business decisions that bankrupted the company and at last to mishandling by Activision, the larger company that had bought it out. Actually, Zork was a trilogy of games, based on a mainframe game sometimes also called Zork but more commonly called Dungeon, but the game that most concerns us here is the first of the trilogy, Zork I, and references to "Zork" in this paragraph should be taken to refer to that game. (Apparently I'm just feeling too lazy to continue typing a single-digit Roman numeral, or something.) Zork is, of course, generally, and rightly, considered a text adventure rather than a CRPG. However, unlike its predecessor Adventure, a.k.a. Colossal Cave, and unlike any later Infocom game until some of the anomalous fruits of the company's Activision-directed twilight years, Zork did have some light role-playing elements. There were two enemies the player had to fight, and, moreover, the character's statistics did influence those fights, in a very rudimentary way. The higher the player's score, the better he was at combat, such that fighting the "lean and hungry gentleman" early in the game was nigh suicidal, but if fought near the end of the game when the player had a higher score he was a pushover. (The other fight, the troll, occurred early enough in the game that the player's score couldn't have been very high yet and didn't make much difference.) Eamon's parser was, of course, nowhere near as good as Zork's, or even as Adventure's, but the combination of combat and text entry is similar enough that I'd be surprised if it didn't take some inspiration from it—or if not from Zork itself, then from Dungeon, the mainframe game of which Zork was an adaptation of the first third. If the 1979 release date for Eamon is correct, that would put it before Zork, but not before Dungeon.
And here I got really unlucky.

In contrast to many systems that came long after it, Eamon is still (more or less) under development today, and still has a thriving fan community. Eamon-related resources on the web include a blog, a Google group, a wiki (still relatively new and under construction), and a website called the Eamon Adventurer's Guild Online with lots of related information and downloads. The fact that Eamon has been under such continuous development touches on a question that came up in my initial post about chronology: which version do I use? The earliest version? The latest? Or do I split the difference and play some version in between? Well, I've given some thought to the matter, and here's what I've decided on: For most systems, I'm just going to go ahead and use the latest version. For systems that have been under development for a very long time and/or are particularly seminal or important to the history of the genre, though, I'll look at every version separately, or at least every version I can find with significant differences from the previous. Eamon, from what I've read about it, certainly seems to qualify on both fronts. So for now, I'll be trying out the oldest version I can get my hands on... but we'll be seeing Eamon again in this blog as we get to the later versions.

The oldest version I could find of the Eamon Dungeon Design Diskette is Version 5... which I suppose implies there are at least four older versions. From what little I can dig up, though, it seems like the essential differences aren't great between these early versions, and in any case the earlier ones may have been lost. (According to the currently rather stubby article about the Dungeon Design Diskette on the Eamon wiki, "early versions of the DDD were unstandardized", and "[t]he first fully standardized version was version 4"... though I'm not totally sure what's meant here by "standardized". Were there several mutually incompatible versions of the DDD floating around in versions 1 to 3?) The first big leap forward, as far as I can infer, occurred with Version 7, which doubled the number of possible monsters, rooms, and "artifacts" (items), tripled the number of types of artifact, and implemented doors and darkness as standard features. (Somewhere around version 6 the diagonal compass directions were added, but that's probably not a significant enough change to be worth a separate look.) So we'll be be taking a look at Version 7 separately... when we get to 1993. For now, Version 5 it is, and that'll have to stand in for Versions 1-6.
I said it was all text; I didn't say they couldn't change the font.

Looking into Eamon was a nostalgic experience for me. Not because of Eamon itself—I first heard of Eamon only a few weeks ago. But Eamon was originally written on the Apple II, in Applesoft Basic. (There were PC ports starting in 1985, culminating (so far) in Eamon Deluxe in 1997... but again, we'll get to those later.) And Applesoft Basic was the first programming language I learned. When I was growing up my family had an Apple II+ computer, and I spent many hours writing my own games on it. They weren't very good games, and truth be told most of them weren't very original games; their core code was copied from listings in computer magazines and books, with some changes and additions. But those were the first computer games I ever made. I don't know exactly where those games are now; the disks the games are on are probably somewhere in my parents' attic, though even if I could find them I have no way of getting the programs off those disks and into a disk image I can read now, and anyway by now the disks may well have become demagnetized. That still doesn't mean those early games are completely lost, though; I'm pretty sure I have hardcopy printouts of the program listings somewhere in my files...

As I said, I first heard of Eamon a few weeks ago, and on looking into it and discovering just how long it had been around and how continuous a community it's had I was kind of surprised I hadn't heard of it sooner... if not in my early childhood when I was still programming on an Apple II+ then later when I tried to take an in-depth look at the history of text adventures (I refuse to call them "interactive fiction"). But in retrospect, maybe it's not so surprising. I may have had access to an Apple II+ at the time Eamon first came out, but what I didn't have was any online presence... not that the internet was then what it is now, of course, then in the age of the 1200-baud modem, but there were bulletin board systems, and that's presumably where Eamon was discussed and promulgated, and that's not something I'd gotten into. And as for finding out about it later in my investigation into text adventures, well, although Eamon games are arguably as much text adventures as they are CRPGs, they've apparently been more or less ignored by the text adventure community... there was an article on just that subject on the Eamon Adventurer's Guild Online site. In any case, if I had known about (and had access to) Eamon back in the day when I was programming my own games on the Apple II+, I definitely would have created a few adventures for it. They might not have been very good adventures, but that's another matter.

Anyway, enough preamble. On to the analysis of the system itself. If you want to play along at home, here's one way you can get a hold of the necessary files yourself: From the aforementioned Eamon Adventurer's Guild Online site, follow the "Play Eamon" link, and then find the link to the download page. (Or just... follow the link at the end of the previous sentence, I guess.) Download the "Entire Eamon CD"; this is a huge collection of Eamon-related materials compiled by Thomas Zuchowski, another notable member of the Eamon community. Unzip the file into whatever directory you want. In the unzipped directory, go to the directory "AppleWin"; this contains an Apple II emulator that can run the Apple II disk images. There are a lot of other goodies included in that zip file, too, but the easiest disk images to use are elsewhere: there is a disk image in the "CD" of the Main Hall disk, but it isn't bootable. You can use it if you want to mess with a boot disk, but if you'd rather use a self-booting disk image, download the "" file from the same download page, and unzip it wherever you choose. The disk image you can start your Eamon adventures with is "D3_001.DSK"; this contains the Main Hall where you can create a new character, as well as the "Beginners Cave" introductory adventure. Using AppleWin, click on the Drive 1 image, navigate to the appropriate directory, and select the appropriate disk image, and then click on the apple icon (second button down in the toolbar) to get started. You should be able to figure things out from there, especially with the help of the player's manual available either in-game or online.

My character, just starting out.  There is a story behind the name "Ratava"... which I won't be telling.  (Actually, it's not really much of a story.)

The CRPG Addict has already posted his take on Eamon, but I wanted to check it out for myself from a player's perspective before creating my own adventure. So I went ahead and created and outfitted a character. In addition to various weapon, armor, and spell abilities (which can increase with use), an Eamon character has three statistics: Hardiness, Agility, and Charisma. I ended up with a character with high Agility and Charisma, but low Hardiness... which might be dangerous, since Hardiness determines how much damage a character can take (as well as how much he can carry), but I went with it anyway. The high charisma, at least, helped in outfitting the character; the higher a character's charisma, the better deals he gets at the shops. I was a little put off at first by how much the spells cost; the documentation seemed to imply that a PC was expected to have access to all four spells, but, with the possible exception of the unpredictable spell POWER, they seemed to cost far more than I'd be likely to afford any time soon. My apprehension proved unfounded; after I'd put him through the Beginners Cave my character had enough money to buy all but one of the spells, and was close to being able to afford the fourth. (Incidentally, in addition to being affected by Charisma, the cost of spells seems to vary slightly on an apparently random basis. If you cancel buying a spell and then try again, you may get different prices. The same is true of weapons and armor, though in those cases there seems to be no way to cancel out of a purchase aside from rebooting... or, I suppose, not having enough money for it.
His fees may, however, be entirely different tomorrow.

(Speaking of weapons, by the way, I found it a bit odd that "complexity" was a measure of a weapon's quality... the higher a weapon's "complexity", the higher the chance to hit with it. The manual even mentions "the quality of the weapon (also called the complexity)"... so why not just call it "quality" in the first place? Wouldn't that have made more sense?)

After having completed the Beginners Cave, not only had he amassed thousands of gold pieces, but my character's skill with a spear had increased by 8% (which made it somewhat unfortunate that the superior new weapon he had picked up in the adventure was a sword), and his armor expertise was up by the same amount (though he still had the same lousy Hardiness... as mentioned before, I gather opportunities to improve the three core statistics are few and far between). He still probably wasn't in any shape to tackle a really hard adventure, but I decided to run him through a few more relatively easy ones (as judged by their rating on the master list and their reviews).
As later events were to prove, not actually that mighty.
I died on the second adventure I tried, though partly due to bad luck; having two fumbles in the same fight (in one of which my weapon broke and hurt me) certainly didn't help, and neither did having my brain overload and forgetting the HEAL spell. When I retried the adventure my weapon broke and hurt me again, and I died even faster. Despite befriending the first NPC I came across, I died fairly quickly on the third adventure I tried, too. Granted, my character's low Hardiness no doubt wasn't helping matters, but still there seems to be rather a dearth of adventures suitable for starting characters straight out of the Beginners Cave... or at least, if they're out there, I hadn't found them yet. I'd kind of inferred this might be the case from some of the documentation; most of the reviews seem to assume an "average adventurer" with significantly better skills and weapons than a starting character would possess, and the master disk (at least the version now available) includes cheat utilities for editing characters and resurrecting dead ones. Still, I thought if I chose judiciously, I could maybe find one survivable by a beginning character, but so far no luck. Anyway, I'd intended to spend more time trying out adventures, but I still haven't had a lot of free time lately, and I want to get this post up before a full week has elapsed since the last one... I do still plan to play a bit more over the next week (and hopefully manage to find an adventure aside from the Beginners Cave that I can survive), but I think I've seen enough to have a good idea of Eamon's capabilities.
Hey, Marcos, my spear keeps breaking.  Can I get a refund?

Incidentally, the player's manual mentions the compass directions, UP and DOWN, and the INVENTORY, READ, ATTACK, and READY commands (the last designates the weapon the character will next attack with), but says that "other commands are either self-explanatory or they are designed to make you experiment". Typing in an unrecognized command, however, brings up a full list of commands the game does recognize, and for the benefit of future players, here are some other standard commands that seem to be more or less universal in early Eamon games:
  • DROP, of course, drops an item you're carrying
  • ENTER has the character try to go into some object or aperture
  • EXAMINE takes a close look at an item or monster
  • FLEE, ESCAPE, or RETREAT makes your character try to run away from a battle
  • LOOK not only redescribes a location, but may find hidden exits
  • OPEN... opens things. (Okay, so maybe some of these commands are self-explanatory.)
  • SAY has your character speak a word (perhaps a password, in some adventures)
  • SMILE or WAVE can show whether a monster encountered is friendly (though in a rather direct way: if they attack, they're not friendly)
  • BLAST, HEAL, POWER, or SPEED casts the corresponding spell (if your character knows it)
Alphonso, if I ever try this adventure again after I'm a little more powerful, I hope we can still be friends...

Also, hitting Return (i.e. Enter) on a blank line repeats the previous command. Individual games may implement other commands as well (or remove some standard commands, especially the spells). Later versions may introduce more commands, but, again, we'll cross that bridge when we come to it.

Combat in Eamon is, to be honest, not particularly interesting. In almost all cases, there's little strategy involved, and little you can do except ATTACK until you or your adversary is dead (or FLEE if the former possibility seems predominant). The behavior of monsters and NPCs in the game is a bit unusual; on meeting the PC, a monster may be either friendly or hostile, the chances of hostility depending on the PC's Charisma and on the monster's "friendliness" (some monsters, like the rats in the Beginners Cave, are always hostile regardless of the PC's Charisma). A hostile monster will, naturally, attack the PC, but a friendly monster will follow the PC around and fight on his side. There is no in-between; a monster is either for you or against you. Either they want you dead, or they'll risk their own lives to protect you. (This is all the more puzzling considering that according to the designers' manual, a value of "2" for the monster's reaction indicates its attitude is "Neutral"... but as far as I can see there's no way for a monster's attitude to ever be set to that value.)

But that's enough about playing the games. Let's get to what this blog is really about: how is it to create new scenarios? Well, as I've already mentioned, there's a program called the Dungeon Designer Diskette that's intended to do just that. As it turns out, though, all the Dungeon Designer Diskette really does, aside from making a copy of the game's main code, is allow you to edit the rooms' connections and the names and descriptions of things and their basic statistics. All behavior and commands are hard-coded in. This may seem to contradict my reference above to new commands in some adventures, but there's a perfectly simple explanation for that: these new commands were implemented by the adventure creator's editing the program code. This doesn't seem to have been considered a hack, either; judging by the designers' manual and the existing games, it seems to have been expected that Eamon adventure creators would edit the source code. That's just the way it was done. There's even a data type editable with the Dungeon Designer Diskette, "Effects", that's nothing but text strings that are never used in any way by the program as it initially stands and can only be displayed by adding code to the main program that accesses them.

This reliance on editing the source code may call into question the classification of Eamon as a game creation system. Sure, it has some utilities for making text resource files, but significant changes in the program's behavior require changes to the source code, and I'm not sure there's a single released game that was created without some changes or additions to the default source code. Still, even if it does require the game creator to edit the source code, it's still a system that was created with the intent of allowing users to create their own adventures, and it's arguable that requiring users to edit the source code isn't all that different from requiring them to use external graphics editing programs to create images. I'll say it qualifies.

On the plus side, of course, this means that potentially everything is customizable. Don't like the default rules for monster behavior, and want to add in some neutral monsters that won't fight for or against the player? Easily done. In fact, I think I'm going to do just that in the adventure I make. Want to give the creatures special attacks and/or vulnerabilities, so a fight consists of more than just the player character and the monster monotonously hacking at each other until one goes down? That's a little trickier, but still doable... in fact, I'm going to do that in my adventure too. Want to make an adventure that you can send more than one adventurer into at once, and that in fact requires the coöperation of two adventurers to succeed? Well... that one would require a lot heavier modification of the source code, I think, but it could still be done. That one I'm not going to do for my adventure, though... though I admit I very briefly considered it. (Maybe when I get to a future version of Eamon...) Some of the existing Eamon adventures have even included graphics.
Okay, you do get one more screenshot with graphics after all.
So, yeah, it looks like creating an Eamon adventure is going to involve some actual programming. But heck, if I was programming in Applesoft Basic as a preteen, I should be able to do it again...