GameAPI: Updates and Map Making

Note: The GameAPI is an effort to implement browser-based games, primarily RPGs, in Drupal. Read the original design document or check out the official forums. The following post has been crossposted there as well.

So, Er, How's It Going?

The first three bullets of the original proposal were:

• All game data stored in external files.
• The default game data files are multi-genre.
• A gamesapi is created, much like the nodeapi.

And the framework is in place. It's not much of a framework, but is certainly past the realm of "proof of concept" and into the territory of "welp, it works". In the coming months, it'll be edging ever close to "aah, this is why he wanted it this way." And, naturally, there are docs and examples in the CVS. It all works too.

The next stage is centered around character creation, and I had hoped to finish that mini-milestone this month. However, after numerous false starts with multiple page forms (to allow race selection to determine what actual classes are available, for instance) and a desire for "characters should be nodes", only recently, per chx's example, do I feel confident about getting it Right. I'll be working on that approach shortly.

Map making: Interface and Design

The real reason for this post, however, is to discuss the map interface. There was some minor and preemptive talks about it on the Gamegrene forums, but I didn't really have a firm grasp on what I was looking for. I believe that now I do, and it's flexible enough to satisfy most needs, whilst being entirely optional. This is solely a design, and little thought has been given to the actual code involved.

What I envisioned the system needed (in a totally non-scientific way):

1. Rooms in external files, per our previous design goals.
2. Multiple rooms in a single file (ie. cities).
3. Cardinal directions and linking with other rooms.
4. Ability to "cost" (in Action Points) to enter the room.
5. Rooms can be literal rooms, "forest path", or "Planet Xenon".
6. Implemented in such a way that visual maps are possible.
7. Rooms are containers of NPCs, equipment, or random encouters.
8. Travelling between rooms needs to be quick, and slow.

Most of the above stuff doesn't need further explanation. It is important, however, that "rooms" can be as big or as little as the user needs, and can contain other rooms, to any depth. It should be quite possible to travel on your spaceship through a solar system (the biggest room possible), choose a planet (a huge room), transport to a city (a big room), visit the bar (still smaller), and rent a bedroom (the smallest). Naturally, if you don't need that granularity, you can certainly just do an "overworld" (visible city locations, terrains, roads) and a "dungeon" (a literal dungeon, a house in the forest, the inside of a city). Entirely up to you. Rooms can be as big or as small as you'd like, and you can mix and match.

In addition, traveling between rooms needs to be as quick, or as slow, as necessary. If I'm at one city, and I want to go to another I've been to in the past, I shouldn't be forced to see page load after page load of mundane "you're travelling on the road to Iganefta" descriptions or, for that matter, click each room/direction necessary to actually get there. I should be able to just look at a map, click on the icon for Iganefta, and be "transported" there (perhaps with some random encounters along the way). On the other hand, when I'm in a dungeon, I shouldn't be able to just click on the Altar of Quest Winning from the entrance and be taken there - I should be forced to travel through each and every room, fighting monsters, solving traps, finding clues, and so forth. Naturally, unless I have a map (or have been here before), there should be a "fog of war" so that exploration and discovery is still possible (even on an "overworld" level ie. "oOOh, I haven't been in this part of the forest before").

How should all this look visually? Take a look at this quick mockup of an overworld (herein, "overworld" is used as "a view of the biggest rooms possible" - terrain, in this case). First, our visual map is a Drupal block, which can be disabled if you've developed something better. Blocks that are grey have not been explored (fog of war). Blocks that are white have been visited by the character. The green ones are cities. Again, realize that this is a mockup, and not indicative of any final coloring or visual decisions. "X" marks the character's current location. The player can travel between "rooms" by clicking a white square (either adjoining or not, as this is the overworld, where travelling is boring) or choosing the adjourning cardinal directions for the particular room the character is in. If the character visits a square with adjoining grey squares, they become visible.

Hovering over a particular (visited) room shows a tooltip that contains a little picture of the room (optional) and some additional meta info. I'm undecided on whether to attempt to use hex tiles (from the GPL'd Battle of Wesnoth project) on the map itself (so that you'd always see them) or whether to just keep them in the hovers. It'd certainly be a beautiful map if you saw them all the time, but I worry about layering information on TOP of it (like character location).

Also in the screen shot is a "Travel to:" dialog. These would be major locations (as defined by the room files) that the player could automatically travel to without incident. Players would also be able to bookmark their own favored locations ("Trading Posting #12" or some such) for a small cost in custom travel fare (Action Points, AP, but that's a discussion for later). If anyone knows World of Warcraft, these bookmarks can be considered custom flight paths, with a cost in AP as opposed to copper and silver.

Comments, concerns, death threats?