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.
SourceForge Project Accepted!
August 2, 2008 by dwheadonFramework design
July 20, 2008 by dwheadonIt’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
July 6, 2008 by dwheadonThe 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.
The over-world
June 23, 2008 by dwheadonOne of the things that I wanted to be able to do with the framework was to be able to re-implement games like Crono Trigger and The Secret of Mana. But in contemplating how the various “levels” of the game would interact I decided to rule out the possibility of an “over-world”. The over-world in Crono Trigger is where you’re running around in miniature form to the various points of interest on the world map. The over-world in The Secret of Mana is where you’re flying around on Flamie the dragon. The over-world in Crono Trigger is just lame. It looks retarded. The over-world in The Secret of Mana is actually pretty cool, but to generalize it to make it work, not on a particular map but on any map the game designer decided to create, would introduce a level of complexity that is unwarranted for a project of this type. In addition not all games will use a flying dragon for traveling around on the over-world. Seiken Densetsu 3 (aka. Secret of Mana 2), for example, uses a giant sea turtle (in addition to Flamie). So it’s just not possible to do this in a way that would apply to all games. Instead the over-world in ARF will be more like the over-world in “Zelda, A Link to the Past”. In this game, the over-world operates exactly like any other level except that while most of the “level” levels have only one exit / entrance, the over-world has many exit / entrances. It’s sort of an in-between level that connects all the other levels together. This doesn’t rule out things like canon travel (Secret of Mana) or teleportation, but the cut-scene that shows the characters flying through the air would not be handled by the framework.
Implementation Language
June 15, 2008 by dwheadon[Warning: this is a fairly technical post] So I’m pretty much set on writing the framework in Python with the aid of the pygame library. Python is a scripting language that I was introduced to when I was working at Intel which has a lot of advantages for beginning programmers. “Why not Java” you may ask being that I wrote Stakeout in Java and extolled the benefits of using Java for that project. Well, Java got on my nerves because of its sluggishness during startup. It is really slow, even on my new laptop, when booting up the virtual machine. Python is much faster at least as far as startup goes which, when you’re developing code, is where you spend most of your time anyway. Also being a compiled language, Java required a lot of preliminary explanation about how to get even the most basic of programs up and running. Since Python is an interpreted language, we can skip all of that. You just write your code and run it directly. In addition, the pygame library takes care of a lot of the lower level graphics stuff, so it’s even easier to work with visual applications. Pygame also has some other features that are specific to game programming (like collision detection) which I plan to take advantage of. Python, like Java, is also cross-platform, so we don’t loose anything there… So what do we lose by moving to Python? As of my last inquiry into the matter, Python did not have an adequate graphical debugger and since its not a strongly typed language, the error messages aren’t always as informative as you’d like. Using Java with the Eclipse development environment worked very smoothly. The debugging disadvantage is a big negative for Python, but given the other advantages (some not listed here), I think it was the right choice.
Prototype Plot #2
June 14, 2008 by dwheadonAs mentioned previously, the other plot idea that my brother Michael and I came up with was more along the lines of the traditional fantasy RPG. It’s not a ground-breaking plot, but its just as good as any of the others I’ve seen. I’m open to any suggestions / alterations. I don’t really care what the plot is as long as there are cool weapons and spells to be had.
The crucible of life was used by the gods to populate the world with living things. The world was a peaceful haven until one of the gods took the crucible for himself and began to create beings which were ugly, vile, and evil. An argument arose over the creation of these creatures and a great battle ensued among the gods. Seeing the terrifying power that the crucible had when used for evil, the gods forged a magical hammer with which they intended to destroy the crucible. The evil one was subdued but it required the united effort of all five other gods, such is the power of evil. Even in light of his own defeat and the threat of his own destruction, the evil one refused out of spite to reveal where he had hidden the crucible. With no other choice, they destroyed the evil one intending to then find the crucible on their own. But unbeknown even to them, the gods were all connected having come from a single source. And death begets death… so their power faded over time and they too disappeared from the earth… and the crucible was lost and became merely a legend.
The story begins several centuries later. A power-hungry general fights for his king to win glory for himself but secretly curses the king and the fact that he himself was not born with royal blood. His men serve him but only because he serves the king. Without the king, he is nothing. In one of his foreign campaigns he stumbles upon the hiding place of the crucible of life. Using the designs left by the evil one, he discovers its secret power and how with it he can create beings without wills of their own; beings that will obey him and him alone. With it too he discovers the power of dark magic. While the evil one can no longer exist in his own right, the power of his spirit can be channeled by those who know how to invoke it. And so he builds an army intending to take over the world…
There are five different types of good magic, one pertaining to each of the good gods. People usually have an affinity for one type of magic or another. Incidentally some have an affinity for two or even three types of good magic but none have been found to have an affinity for all five. Only one who can harness the power of all five gods will be able to defeat the minion of the evil one and wield the magical hammer, or so the legend goes. But the hammer, the only thing which can save the world, has been lost. Like the crucible, the memory of it had faded over time.
A humble farmer boy finds a hammer in an ancient cave. In his hands it feels light and yet powerful. He inquires with the elders as to its origin and discovers that it is the legendary hammer. What surprises them even more is that the boy is able to wield it while no one else can bear its weight. It turns out that this unlikely boy has an affinity for all types of magic, but he is entirely untrained. He will have to travel to five different lands to learn the magic of the good gods so that he can harness them all together to defeat the evil general. His quest is long and perilous and he must travel alone. Will he be able to complete his mission and save the world?
That’s pretty much it. I’m not going to go to the trouble to fill in the details just yet. There’s plenty of time for that. In the meantime I have a lot of code to write. My future posts will deal more with the technical details of the framework: things that will limit the types of games that a designer will be able to make. In fact, in one of my next posts I’ll explain how the framework will fail to achieve one of my initial goals (i.e. to be able to re-implement Crono Trigger). I have good reasons! Lots more to come…
Prototype Plot #1
June 6, 2008 by dwheadonAs with Stakeout, I plan to make a prototype game implementation to show how the framework can be used to create a game. The first step in implementing a prototype is coming up with a plot / storyline. I brainstormed with some of my brothers this past weekend and came up with a couple of different ideas…
One idea was to create a story around the (tentative) name for the framework. In other words, a story where the protagonist is a dog. My brother Nathan (9) latched on to this idea and ran with it. The proposal goes like this: The existence of dogs is the only thing that has kept feline race from taking over the world which is currently dominated by humans. [This brings to mind many scenes from "Get Fuzzy", one of my favorite comic strips.] But the cats have discovered the source of dog power which is concentrated within the bone of dogness. If the cats can find this precious artifact and destroy it, there will be nothing left in their way from taking over the world. The protagonist is a member of a team of dogs who are tasked with “fetching” the legendary bone of dogness and protecting it from the evil cat overlords thus saving the world from a tragic fate…
It’s a rather ridiculous story but somewhat amusing. I sort of like it because it builds on the (tentative) branding of the framework. Such a story would certainly be unique. I don’t think I’ve ever seen an RPG where the protagonist was a canine. But I tend to like the traditional fantasy RPG where you have swords, armor, and magic so I’m leaning more towards the other idea… [see next post]
Name
June 2, 2008 by dwheadonI’m trying to come up with a name for the framework. My initial thought was to call it “ARF” which would stand for “Action Role-playing (Game) Framework”. I want to call it an “action role-playing game” because I was inspired by console role-playing games of the likes of Secret of Mana and Chrono Trigger for the Super Nintendo. I plan to pattern the framework primarily around these two games to the extent that they could be re-implemented using the framework. By the way, if you don’t have an SNES but would like to check out these games, you can use an emulator to play them on your PC. I recommend ZSNES.
An acronym like “ARF” lends itself well to a logo / mascot involving a canine. I’m not entirely sold on this, though. I’m not sure if a dog accurately portrays the vision I have for the framework. Any suggestions for a different name / logo / mascot? I expect a flood of comments on this post from the many followers of this blog…
Vision
May 28, 2008 by dwheadonThe important thing to establish initially is where to draw the line between what the framework will handle and what the user will be required to program. My goal is to supply a minimalistic framework that will allow the user to create and play an entire game (plot) from beginning to end without having to do any real programming. To play a game from beginning to end, the user will need to be able to do the following things:
- Show cut-scenes
- Move around in the world
- Interact with other characters and objects
- Acquire items
- Engage in combat
Just because the player has to be able to do these things in order to play through the game, doesn’t mean it has to be fun. For example, a minimalistic battle could simply be a situation where the enemy spontaneously dies as soon as he approaches the protagonist. Such a game would be trivial to beat because the protagonist could never die. This would not make the game very fun. It would be reduced to a simple walk-through. But that’s the motivation for the student: make your game fun. Combat systems are unique from game to game. So implement your own unique combat system to incorporate whatever you want: different types of attacks, magic spells, blocking, dodging, etc.
Similarly for items: the user will probably need to acquire certain items as part of the plot in order to complete the game (e.g. you have to bring the magic hammer to the blacksmith so that he can reforge the sword of light which you need to defeat the dark lord). Some items will be discovered in the world, some will appear after you defeat an enemy, some will have to be purchased. Usually items have some sort of effect on the player. The most obvious are things such as weapons and armor. Usually these will increase your attack or defense attributes. But outside of the acquisition of the item and its ability to influence the progression of the plot, the framework will not determine the effects that items have on a player.
This is what I mean by a minimalistic framework.
Purpose
May 27, 2008 by dwheadonI’m creating this blog to air some ideas that I have for an RPG (role-playing game) framework in the hopes that I will be able to generate some interest and get some feedback. The purpose of the framework itself is to create an engaging context in which someone could be introduced to the world of programming. See Stakeout for a similar project that I have developed. I’m moving away from Stakeout because of the pre-designed nature of the game. With the RPG framework, the student is the one who designs the game (plot, characters, story-line, artwork, etc.) and uses the framework to implement it. The fact that the student creates his own game should generate a higher level of ownership and interest. After creating the game, the student is encouraged to learn programming in order to extend the framework to make it more interesting.

