Press Restart

I don't know whether anyone is still following this blog, after it's lain fallow for three years, but in case anyone is... I just want to let you know that the blog is being restarted at a new site.  Namely, instead of running it on Blogger, I now have a Wordpress site with its own domain, http://www.comparativecreation.com.

When I first started this blog back in 2013, it was basically started on a whim with no preparation, and I think that shows... and that's why I didn't manage to keep it going for more than a couple months.  Now, for the relaunch, though, I've put in a lot of preparation, and I'm determined to be in it for a long haul.  So, if there's anyone out there still following this blog, join me, won't you, at the new site?  Again, that's http://www.comparativecreation.com.  See you there!

Eamon: Recap and Redactions

Okay, I admit I'm not quite where I hoped to be in terms of being ready with the next post.  I'd hoped to have played a few more Eamon games to get back in the swing of things and to have a bit more to say.  But I've been enormously busy the last week, and haven't had any free time to speak of to devote to the matter.  Still, I said in the last post that the next post would "seriously, seriously be up in less than a week".  So I figured I'd better follow through on that.  After all, I said "seriously" twice.  That's serious.

Anyway, I suppose even without having played more Eamon games, it's worth making a post just because it's been so long since the last post on Eamon it's worthwhile just briefly reviewing what we're up against—as well as correcting .  Eamon is sort of a text adventue / RPG hybrid that was one of the first game creation systems I could find... I said it was the first before, but that was before I decided to acknowledge the fuzziness between level editors and game creation systems, and to go ahead and count the former as well; there are some games with level editors that predated Eamon (and we'll get to those when we finally finish with Eamon).

I guess there's no need to recap everything about Eamon, though, since you can always read the earlier posts to refresh your memory if you're so inclined.  I did, however, want to address a few matters that I stated in the earlier posts that turned out to be incorrect.  I'd planned to discuss these along with my further playing experience, but, what the hey, I guess there's really no reason those have to be in the same post.  So here goes.

First of all, I'd mentioned some commonalities between Eamon and the seminal text adventure Zork, and surmised that the former likely took some inspiration from the latter—or if not from Zork itself, from its mainframe predecessor Dungeon.  Turns out that's not the case—or at least so I infer from, among other things, the fact that the Eamon documentation mentions the original adventure game Colossal Cave but never Zork or Dungeon—and, in any case, it seems to have possibly predated Zork, and Dungeon was only available on a mainframe that Eamon creator Donald Brown is unlikely to have had access to, so it was probably an untenable assumption in the first place.  In any case, it's not particularly surprising that Donald Brown and the creators of Dungeon independently decided to add RPG elements to a text adventure, given that Dungeons & Dragons was a big part of the zeitgeist at the time.

It also turns out I was wrong in supposing that the diagonal compass directions were added around version 6; they were there in Version 5 as an optional feature, though I think for my adventure I'll stick to the four cardinal directions, to limit myself as much as possible to what would have been available in the earlier version.  I was also mistaken about there being "no in-between" between monsters being friendly (and accompanying you and risking their lives to fight your foes) and hostile (attacking you on sight)... it is indeed possible for monsters to be indifferent to you, neither following you nor attacking you.  In fact, it seems that the algorithm checks the monster's hostility chance twice: if the first check renders the monster non-hostile, it checks again (with the same probability based on your character's CHARISMA as well as the monster's own settings), and only if the second check also turns up non-hostile is the monster actually friendly.  This may not have been the case in the earliest versions of the game, but was certainly true by the time of Version 5.  Furthermore, some Eamon adventures do include monsters with special abilities, another feature I said I was considering putting into my game.  There are other interesting features put into some of the Eamon adventures, too, but I'll get to that in the next post when I discuss my play experience in detail... suffice to say that while Eamon was still necessarily unsophisticated compared to later games, it attracted some imaginative authors who stretched its capabilities in interesting directions.

I'd say more, but perhaps I should leave that for the next post.  I do want to get this up within less than a week from the previous post, and I've got about five minutes to go.  The next post should describe my experiences playing Eamon games, though, and the post after that, we'll finally get into what this blog's all about as I start really creating an adventure with Eamon.

Going Pro

Okay, yeah, wow.  It's been way more than a week now since my last post.  I know.  I know.  But I haven't abandoned this blog, and I determined at least not to let the entire month of January go by without an update.  (Hey, it's still January in my time zone.  I don't know when it is where you are.  Though in any case it's very unlikely that it's still January when you're reading this...)

Furthermore, in the interests of doubling down and breaking two promises at once, this post will not be about Eamon, as previously professed.  Yes, I will get back to that, and I won't take another month and a half to do it.  But something happened related to the last post that I felt I ought to mention first.

So, last month for the first time I attempted Ludum Dare, a game competition in which participants create a full game from scratch in 48 hours, based on a provided theme.  I didn't particularly care about the competition, per se; I just wanted to see if I could create a game that quickly.  Perhaps somewhat audaciously, I decided to see if I could in 48 hours (actually more like 24 for various reasons) create a game in javascript and HTML5, despite never having done so before.  Somewhat to my astonishment, I succeeded.  My creation may not have been a great game, but it was a game, and it more or less worked, and it even had a level editor.

Halfway through the last of five levels of Underequipped.

So far, that's all old news; I went over all of that in my last post.  But there's one thing I didn't mention in my last post, for the rather logical reason that it hadn't happened yet.  I didn't really follow up much with Ludum Dare itself; the guidelines recommended rating other games in order to get votes, but I was extremely busy in the weeks following the competition, and I never got around to doing so—as I said, I wasn't really in it for the competition anyway; I just wanted to make a game.  (I do feel a little guilty about not supporting the other entrants by voting and commenting on their games, though... but I seriously had virtually no free time in that time period.)  But a few weeks ago, I told some friends about what I had done, and showed them the game.

Little did I know (to use the most melodramatic sentence opening possible) that one of said friends was in the process of putting together a video game company.  And he didn't have a programmer.  He and his business partner were planning on teaching themselves programming and trying to tackle the job themselves, but at that rate he expected it would be a year and a half before their first game was out.  But he was impressed enough with what I had been able to accomplish in 48 hours (though I hadn't really thought it was all that impressive) that he asked if I'd help him out with his game.

I agreed, and he invited me to come to his place that Friday so he could show me what he had so far.  He and his partner were putting together the game in Unity; I had heard of Unity, of course, but I knew very little about it—and since it was, I thought, more of an engine than a game creation system, per se, it wasn't on the agenda for this blog, either.  Still, I thought I ought to be prepared, so I did some reading up of the Unity manual, as well as a tutorial on C#, the language he and his partner wanted to use for the scripting.  I didn't get all that far before our meeting—only as far as Creating and Destroying Game Objects in the Unity manual, and Using Attributes in the C# tutorials, but at least I knew a little more about than I had.

This is just the Unity splash screen.  I can't show you the specific game I'm working on, not because there's nothing to show, but because I think at this point it's still supposed to be kind of a secret.

So, feeling a bit less prepared than I would have liked to be, I showed up on Friday, and he told me a little more about the game, and showed me what he and his partner had done so far.  Most of the graphics were in place for the introductory level, but none of the scripting had been done yet.  I figured I may as well see what I could do, so I started right in and tried getting things working, with a lot of help from web searches and posts they turned up on Unity Answers.

And so, somehow, despite never having touched Unity before—or C#, for that matter—I ended up pretty much programming the core functionality of the level that evening.  This impressed him enough he offered to make me a full partner in the company.

(To be fair, though, the gameplay was relatively simple, and the coding wasn't that complicated; someone experienced with Unity and C# could probably have easily done it all in well under hour—it took me much longer only because I kept having to look up things that anyone better versed in Unity would already know.  All the code amounted in the end to under 150 lines.)

Of course, I don't know what's going to come of this.  After the first game's done, he has a lot of other games in mind to do, and his goal is to keep churning them out at a regular basis and making some decent money from them—but of course there's no guarantee the goal will be realized.  Still, it's something, and it could end up leading to something big, even if it's not guaranteed.

So, yes, the short version is that thanks to a silly little game I created in about a day, I somehow ended up becoming a partner in a video game company.  This is not an outcome I anticipated, but what the hey.  I'll take it.

Okay, my next post will seriously, seriously be up in less than a week.  And it will seriously, seriously finally get back to Eamon.  Very sorry for the delay.

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.)

Q

Blank floor tile

Z

Wall

P

Pit

Y

Cracked Wall

M

Bars

V

Locked Door

2/4/6/8

Fireball Machine

W/A/S/D

Monster Type 1

T/F/G/H

Monster Type 2 (fireball spitter)

I/J/K/L

Monster Type 3 (invulnerable to arrows)

B

Gem

X

Start

C

Goal

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.

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 Odyssey² 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.

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.