I’ve been working on a design document that outlines the game as I finish things up. It’s slow going, but every time I finish a small section of it, I get almost the same thrill as finishing the same section programmatically. I guess I know that when this piece is completely done, I’ll have a much easier time finishing up the beta release and porting everything over from the bland black/white layout to something that is much for fitting for an RPG.

From the beginning I wanted browser-based games to contain features that make other MMO’s so easy to get in to. Not as much page refreshes, modular windows, beautiful graphics and proper fight timers are just some of the things I opted to include in Rising Legends. As well, I worked a long time on the UI, ensuring ease of use, so first time players can just jump right now. From the programming side of view, I had to take some time out to implement my own version of the JQuery Tools tooltip and overlay libraries to ensure speedy load times. While JQuery Tools provides some great animations, I found that not only were they too flashy, but they lagged. The more tabs you had open, the slower it went. While my interpretation of it isn’t nearly as flashy, it cuts down on a lot of the code cutting out about 6KB of things that I didn’t need. While 6KB doesn’t seem like a lot, since network speeds are now our bottleneck instead of processing power, it will start to add up as more players join up.

I figure I will add a brief explanation of a basic version of the overly code, since it is an interesting topic and very easy to implement. As well, it allows for perfect positioning of elements.

In closing, I just wanted to link you all to an in-dev version of the UI that will be pushed out with the beta release: http://boba.feethavebeen.com/template1/

Place 3b into 2c while holding 4d adjacent to panel a4.

Now, any normal person will have absolutely no idea what’s being talked about. And that’s ok, because there isnt any kind of legend included within. For example, if I included a legend like the following, you would have no trouble understanding what I was talking about.

a4: Cabinet Side Wall
2c: Hole on bottom left of Cabinet Side
3b: Screw
4d: Cabinet Door

Hey now, magically that all makes sense. And in an instruction manual, where you have a set number of components, it’s alright to include things in an abbreviated manner.

But why would you apply the same logic to code? Why would you force variables into concise statements when it would make more sense to expand them? After all, L1 makes less sense than Line1 does right? This logic works great for variables, but fails a little when you move to function arguments. Essentially, the very fact that it is great for describing what a variables’ use is, causes it to be large, and accumulating upwards of 2 or 3 of these verbose variables into a function can become tedious. No one wants to read two or three lines of function arguments.

While thinking about the matter on a recent project that I have been working on, I realized that many frameworks had already stumbled upon the problem, and solved it rather quickly. The idea is that in a function, we can leave room for a variable length of arguments for any function, and still have “required” values. It is a little complicated but in a code example, we can see the value of such an idea:

Way 1: Concise
function call($var1, $var2,$var3,$var4,$var5)
{

}

Way 2: Verbose
function call($var)
{

}

No it isn’t a typo, Way 2, the Verbose way really does have only one argument, but it will be treated as an array. Not a regular array, because those are messy looking in practice, but a string separated by both colons and commas and returned to the function. The bonus of this is that when you go about developing an application, you can see what variables a function requires at a glance.

Concise Argument Definition:
call(135,12331,123,41344,384192′);

Verbose Argument Definition:
call(‘takeout: 135, initial: 12331, custid: 123, accountid: 41344, custphone: 384192′);

Now you can clearly see why they are called verbose arguments, but also why we would use them. When perusing your code after a few days, you seldom remember what a badly named variable does. In this way, you can, at a glance, see what variables a function will accept and you can define them in any way. In the first example, if 135 and 12331 were switched, you would get an error since you can’t subtrace 12331 from 135 without resulting in a negative number. However, with verbose arguments, you can’t go wrong. You can easily see what you are setting each argument to, and you can easily set things right, incase you mess up.

One could obviously argue that the same method can be achieved using arrays, but arrays are ugly, and since programming is an art form, we try and stay away from ugly.

As for verbose arguments, they are definitely a welcome addition to any piece of software, and it is well worth the few extra minutes of programming to cobble together a quick function that will handle everything for you. The function will take a string verbose input, and split it according these rules, and return the new array back.

Rules

• Variable names are before a colon.
• There must be no space between the variable name and the colon (ie. varname: is acceptable but varname : is not)
• The value for a variable must come after the variable (with or without a space)
• Multiple variables are separated with a comma after the variable value (ie. varname1: angelo, varname2: another)

function parse_args($args)
	{
		$e = explode(', ',$args);
		if(count($e) <= 1)
			$e = explode(',', $args); 
 
		$num_e = count($e); 
 
		for($i = 0; $i < $num_e; $i++)
		{
			$t[$i] = explode(': ',$e[$i]);
				if(count($t[$i]) <= 1)
					$t[$i] = explode(':',$e[$i]);
		}
 
		// Parse to array[key] = value format
		$num_args = count($t); 
 
		for($x = 0; $x < $num_args; $x++)
		{
			$tmp[$t[$x][0]] = $t[$x][1];
		}
 
		return $tmp;
	}

Hopefully, after incorporating it into your own applications you’ll see the benefit of something like this.