SourceForge Project Accepted!

ARF was just accepted as a SourceForge project and I’ve been busy creating a website for the new project. It’s finally done and can be found at arf.sourceforge.net. Most new material from here on out will be posted there unless it’s more of a speculative nature. Check it out and let me know what you think.

Framework design

It’s been a while since my last post. I’m currently working out the structure of the framework design. It’s a rather involved process so that’s why it’s taking me so long. I’m using FreeMind (a program I recently discovered) as sort of a poor-man’s UML (Unified Modeling Language). Here’s the current state of affairs. It’s not finalized so I won’t describe it in detail just yet. Most of the GameObjects will be reminiscent of Zelda since Zelda has the richest set of objects of any game out there; thus it should cover most use cases. I’m modeling the animation sequences around Chrono Trigger because it has some of the most complex dialogs and cut scenes of any action RPG I’ve seen.

The initial version of the framework won’t implement all of these features, but I want to design it so that it can accomodate all the features that will eventually be supported.

World breakdown

The game designer has the task of creating the world, but creating an entire world is a rather daunting task. It will have to be broken up into some smaller, more manageable pieces. In ARF I plan to split it up in a pretty traditional way. I will mostly follow the fairly standard design which is used in “The Legend of Zelda: A Link to the Past”. The world hierarchy will consist of (from highest to lowest) levels, floors, rooms, and elevations.

For most games, the first layer of granularity is the “level”. In Zelda the level transition is rather obvious (the black circle fade-out / fade-in). When you exit and then re-enter a level all the enemies, switches, and movable objects are reset to their former positions and status. Transitioning from level to level is usually accomplished by entering a door (e.g. a dungeon or palace). Zelda also has a non-traditional level transition whenever you use the magic mirror. I hope to make something like that possible, but it will be an advanced feature that will require some special coding. Other games like the Secret of Mana don’t require a door to transition from level to level. For example, entering or exiting a forest could signal a transition in and out of a level. This should also be possible to do in ARF.

A “floor” is the next level of granularity. Floors consist of a bunch of rooms that are connected together through doorways (dungeon) or passageways (overworld). Only the rooms of the current floor are accessible to the character. Floors are usually traversed by going up and down a staircase. When the character goes up these staircases, the screen will fade out / fade in and the character comes out facing the opposite direction that he faced when going in. In Zelda, these staircases are always found at the top of a room with an appropriate up or down arrow over the doorway. This location (the top of the room) isn’t a restriction ARF will impose on staircases, but it will be much less intuitive to portray the direction that the stairway leads (up or down) if placed on any of the other three walls of a room. Staircases should not be placed in the center of a room because this looks very confusing from the isometric viewpoint. The other way to move between floors is to fall into a pit. If there is a corresponding room on the floor below, the character will fall into that room. Otherwise, he will fall into the bottomless pit and either die or magically be returned to the place where he fell in (usually with a reduction in health). Floors don’t make much sense in the overworld level unless you implement a cloud or subterranean floor.

As mentioned previously, floors are made up of a set of interconnected rooms. Within a room, the screen will scroll with the character as he explores the room but will stop scrolling when the screen reaches the edge of the room. The rooms are traversed by doorways. When the character enters a doorway, the whole screen will be scrolled to remove the former room from the view and show the next room. As with most games of this sort, enemies will be restricted to the room to which they are associated. They will not be able to follow the character into the next room even if it’s an open doorway or passage.

Within a floor you can have different elevations. Elevations are usually traversed by climbing a ladder or set of stairs within a room (as opposed to staircases which are used to traverse floors). The player can also jump down from upper elevations to lower ones in places where there aren’t any guard rails separating the elevations. The character can only interact with enemies, other characters, objects, and obstacles that reside on the same elevation. An exception will likely be made for projectile weapons. Being free of obstacles from other elevations allows for an overlapping effect where the character can go over or under other parts of the room:

The illusion of levels can be created by having plateaus within a single elevation:

Notice that there aren’t any stairs or ladders separating the upper elevation from the lower elevation. This can make for more fluid landscapes. The problem here is that the only thing preventing Link from attacking the enemy on the alternate level is the length of his sword. This doesn’t turn out to be much of a problem in this case, but it could be in other situations.

I won’t go into detail here about plateaus because they not part of the hierarchy of the world. Rather they are just another feature of the landscape like trees and bushes.

For the most part, designing a level will not require any programming. You simply establish the various levels, floors, rooms, and elevations that make up your world and encode it in a data file. This data file will either be in XML or in Python source. I haven’t decided which to use yet. Each has its own advantages and disadvantages.