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.

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 siegetheday.org

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.

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.

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!