Tuesday, August 23, 2016

An end, and a beginning

How lucky I am to have something that makes saying goodbye so hard.
If you've been paying attention to my blog, I don't delve into personal stuff often. Or at all, really. This is a reasonably big time in my life, so I thought I'd break with "tradition" - much as a barely-active 5-year old blog can have, at least - and talk a little bit about myself.

For starters, I'm now a student of Computer Science at the University of Texas at Dallas. As I type this, the second day of class has come to an end, and I'm sitting in an empty residence hall lobby late at night; the only sounds I can hear are the air conditioning, my fingers on the keyboard, and the celebratory welcome banners brushing against the walls in time with the A/C. I'm still suffering from the stubborn vestiges of a cold I came down with over the past weekend that also took out several of my newfound friends and colleagues. Additionally, the internet has been out in my dorm room since I've moved in, so I've had to use the lobby Wifi for email and the like instead. Regardless, college life has been fun so far. Plenty of friends to hang out with, lots of campus events to go to, friendly faculty to network with - you get the idea. Contrary to popular opinion, there's more to life than what's on the internet. I've barely noticed I don't have a dorm connection except when I have to do something I can't do from my phone.

From a high school student's limited perspective, college is an interesting place. You're given enough freedom that you're basically in a loosely-padded training environment for being an adult. You're given opportunities to seriously succeed, and to seriously fail, both by your own hands. You're given the freedom to stay up at 2AM to go to Walmart to get milk, or to sit in a lobby blogging, if you want. You're free to make your own choices, and live with the consequences; there's relatively few instances where there is someone looking over your shoulder, telling you what you should and shouldn't do. For someone who has potentially lived their entire life with someone else at the wheel, that kind of freedom can be a very scary feeling, and a daunting adjustment. But enough about that.

For someone who lived at home with family their whole life - like me, for example - being away from family and old friends can be a bitter pill to swallow. For almost 2 decades, I grew used to being able to see parents and siblings when I got up, to them being there when I went to bed. I grew used to having conversational partners in my siblings that I could engage whenever I wanted, who held interests similar to mine. Being away from people that you've built such powerful connections with can be a difficult ordeal, indeed. But, it's something you have to learn to cope with. You call friends and family as often as you can, and visit when possible. You find new friends that you can trust and open up to. Maybe even discover that you have family members living nearby and visit them.
Eventually, you might lose these people too. If I get a Masters out of state, and decide not to move back to the Dallas/Richardson area, this whole process of loss will repeat. And I'll start from square 0, again. I wouldn't blame anyone in my shoes for not feeling a little depressed over the whole situation, for wondering whether or not it was worth it to build all those precious connections in the first place, only to painfully tear them all down again.
However, at the time, I know my feelings were real. I know that the memories of elated moments with friends and family were genuine, were not fake; that they were caused by me being sincerely happy to be with them in that instant. And those memories - those fleeting, ephemeral instants in time - stick with you forever, regardless of how long your friendships last. And nobody can take them away from you. I don't want to stop making them because I might be afraid the people involved might eventually leave me. It's a common occurrence, with an element of certainty to it: People drift away over time, and finally, die. But until the day that you yourself leave this earth, those memories will faithfully serve as a living testament that the people you cherished so dearly ever existed. And I think that's a beautiful thing.

So here's to making many more memories, with the many people I've met and will meet. To my parents, thank you. To my dear old group of friends, goodbye, I wish you all the best. And to all my fellow incoming freshmen: Congratulations.
Life is a continuous cycle of losses, you see. And the greater the joy at your gain, the greater the sorrow will be at your loss. But as long as we have the memories of those happy times - indeed, because we have those memories - people are able to go on. 

Thursday, May 19, 2016

FuzzBuzz and the Art of Programming

Programming: It's as much an art as it is a science. The general distinction between art and science being the realm of subjectivity - in other words, while in the realm of science, "correctness" is still debated, nobody is under the illusion that there is more than one "correct" solution. Art, on the other hand, has no single "correct solution," though at the same time, the merits of each solution are generally weighed against each other solutions, debated, and so on.

Programming is a mix of both: There are certainly "solutions" - algorithms, programs, etc. - that can be objectively proven without a shadow of a doubt to be ineffective or outright incorrect. There is also the possibility of an algorithm that solves the solution, but is objectively inferior to another, such as an algorithm that runs in O(n) time versus one that runs in O(1) time. On the other hand, there is a fair amount of subjective nuance involved in arriving to a correct solution. Design methodologies, languages, and APIs all come and go in a technological blink of an eye, and each will have its pros and cons, its proponents and its skeptics.

Nobody - sane, at least - involved in all this is under the impression that there is One True Way to do things. You could lock several seasoned programmers up in separate rooms, all of whom subscribe to the exact same design methodologies and use the exact same programming languages, ask them to design a program, and they would all likely emerge with completely separate, and likely equally or near-equally satisfactory, solutions. So, without further ado, let's talk about a simple programming problem, and some possible solutions to solve it. At the end, we'll discuss for a quick minute about which of these solutions someone might actually end up using.

The problem in question is one I've named FuzzBuzz, which was definitely not a reference to an overused programming interview question. To solve FuzzBuzz, one must write a program that considers the numbers from 1 to 100, inclusive. For each number, if the number in question is even, the program must print "Fuzz." If the number is odd, the program must print "Buzz." If the number is a multiple of 3, the program should ignore its even or odd nature and print "FuzzBuzz" instead.

This is an intentionally simplified problem, both to make it easy to make multiple solutions, and to make the solutions themselves clearer. By the time you finish reading this sentence, I bet you'll probably have thought of at least one way to solve this problem, but let me go over a couple first.

First up is probably the one that came to everyone else's mind, just a simple restating of the problem's definition in code.

for x in xrange(1, 101): # range/xrange stops at the integer before the 2nd argument
    if x % 3 == 0:
        print "FuzzBuzz"
    elif x % 2 == 0:
        print "Fuzz"
    else:
        print "Buzz"

Not really a whole lot to talk about with this one; like I said earlier, it's probably the first one you thought up yourself - it was the first one I came up with, as well. Honestly, if this were a real-world problem, most people would (and probably should) stop here. But innovation never sprung from a contented mind, right?

So, for our next solution, let's limit ourselves in some way. The modulo operator is pretty central to the prior solution, so let's take that out next.

def is_multiple_of(number, mul):
    """Return True if number is multiple of mul, false otherwise.
    Okay, so here's how this works: Normally, Python - and most
    other programming languages - chops off the decimal part of the quotient
    if both terms are integers, i.e, integer division is performed. However,
    if one of the terms is a float, then the decimal part will be kept.
    Any number plus a decimal part is going to be greater than simply the number itself,
    so we compare the two. If number is in fact a multple of mul, then there will be
    no decimal part, and both sides of the expression will be equal."""
    if float(number) / mul == number / mul:
        return True
    else:
        return False


def multiple_of_three(number):
    return is_multiple_of(number, 3)


def multiple_of_two(number):
    return is_multiple_of(number, 2)
    
    
for x in xrange(1, 101):
    if multiple_of_three(x):
        print "FuzzBuzz"
    elif multiple_of_two(x):
        print "Fuzz"
    else:
        print "Buzz"

Still pretty straightforward. Not having access to the modulo operator means we had to basically reinvent one ourselves, though. But we could go further still, couldn't we? How about no floating-point math?

def is_multiple_of(number, mul):
    """Return True if number is multiple of mul, False otherwise.
    So again we're exploiting the properties of integer division.
    For any divisor, there are at least two pairs of two consecutive dividends that will return
    the exact same quotient under integer divison, and the smaller number in each
    is a multiple of the divisor. All we have to do is check that number
    is the smaller of the pair. We do that by seeing if the result changes
    if we subtract 1. If so, number is the smaller of the pair (i.e, number - 1
    is part of some other pair), so return True.
    Otherwise, we were given the larger of the pair, or alternatively,
    some completely different number, so return False.
    """
    if number / mul > (number - 1) / mul:
        return True
    else:
        return False


def multiple_of_three(number):
    return is_multiple_of(number, 3)


def multiple_of_two(number):
    return is_multiple_of(number, 2)
    
    
for x in xrange(1, 101):
    if multiple_of_three(x):
        print "FuzzBuzz"
    elif multiple_of_two(x):
        print "Fuzz"
    else:
        print "Buzz"


Now things are getting ever-so-slightly hairy. But let's get dangerous now. How about no Boolean logic whatsoever?

from collections import deque
sequence = deque(["Buzz", "Fuzz", "FuzzBuzz", "Fuzz", "Buzz", "FuzzBuzz"])


def next_in_sequence():
    """Return next string in FuzzBuzz sequence.
    The FuzzBuzz problem follows a pattern:
        * Odd
        * Even
        * Multiple of 3
        * Even
        * Odd
        * Multiple of 3
    All we have to do is keep track of where we are in the sequence.
    To accomplish this, we use a deque and a little bit of pushing and popping
    to keep from having to either pre-generate the entire sequence beforehand,
    or from having to use an iterator.
    """
    next = sequence.popleft()
    sequence.append(next)
    return next


for x in xrange(1, 101):
    print next_in_sequence()

Alright, now we're talking. Admittedly, you probably saw this one coming if you were running the programs alongside reading this article - once you recognize the pattern, this solution is pretty obvious. But let's make one final push: No modulo operator, no math, no Boolean logic, and no loops.

from collections import deque
import sys
# Python allows the user to manually set the recursion limit.
# So, we exploit this by setting it to 101, which simulates the number of
# loop iterations we'd execute if we were using a loop.
# Eventually, we'll exceed this number, and Python will throw
# a RuntimeError, essentially accomplishing the same thing as
# a regular for/while loop.
sys.setrecursionlimit(101)


sequence = deque(["Buzz", "Fuzz", "FuzzBuzz", "Fuzz", "Buzz", "FuzzBuzz"])


def next_in_sequence():
    """Print next string in FuzzBuzz sequence.
    This is identical to the deque solution in sequence.py, save for
    printing out the next string instead of returning it, and the recursion bit,
    so go see sequence.py for an explanation of what's going on here.
    """
    next = sequence.popleft()
    sequence.append(next)
    print next
    next_in_sequence()


try:
    next_in_sequence()
except RuntimeError:
    # swallow the eventual exception due to recursion taking one step too many
    pass

I feel now is a good time to stop and discuss the various solutions, now that we have an ample amount. Like I mentioned earlier on, if this were a real-world problem, I imagine most people using the first solution. It's clear, concise, and gets its point across without needing much in the way of hand-holding. It's easy to extend if we need to tackle additional multiples, as well.

Most of the rest of the solutions are pretty silly if we examine them without the restrictions we came up with. The modulo operator is a pretty useful tool for this problem, so it makes no sense to try to work around it, or reimplement it with our own code. I could see an argument being made for the non-recursive sequence solution - some might consider it more "elegant" than the original solution, though obviously that's up for debate.

Some might also think the sequence version is faster, considering the O(1) performance time of deque.popleft() and deque.append() (collections.deque is implemented as a doubly-linked list under the hood), but at least on my machine, the initial solution is faster when testing 10,000,000 numbers, completing in about 3.1 seconds versus 3.3 seconds for the sequence version. After some fiddling around, I was able to produce a variant on the sequence solution that ran in about 2.9 seconds on the same set:

from collections import deque
sequence = deque(["Buzz", "Fuzz", "FuzzBuzz", "Fuzz", "Buzz", "FuzzBuzz"])


# Binding oft-used functions to local scope results in a speed increase
# due to decreased variable lookup time
popleft = sequence.popleft
append = sequence.append


for x in xrange(1, 101):
    # Moving the function's code to the loop body removes the function call,
    # which actually increases performance slightly
    next = popleft()
    append(next)
    print next

By this point though, we've lost a fair amount of readability, which was one of the main reasons to use the sequence solution. On the upside, we have a reasonable increase in speed, which might be useful in a performance-critical application. On a side note, the performance of the other solutions is pretty abysmal in comparison; the modulo-less solution ran in about 8.5 seconds, whereas the float-less solution ran in about 6 seconds. As for the recursion-based solution, it segfaulted on my machine before it could actually complete the 10,000,000-iteration loop.

So, to summarize: Programming is about 50% art and 50% science; there's usually more than one demonstrably correct solution to the problem, and on top of that, there's often some fair room for debate about which of the solutions one should proceed with. We presented a simple programming problem, came up with some possible solutions for it, and discussed their pros and cons.

As an added bonus, I've set up a Github repository at http://github.com/DangerOnTheRanger/fuzzbuzz that contains all the solutions in this article, as well as reference output to test your own solutions with. If you come up with a solution you like, regardless of its performance or what language it's written in, send me a pull request, and I'll add it to the repo.

Thursday, September 5, 2013

Ambiguous developer intention in fighting games

This is a topic that really grinds my gears: Ambiguous intention from developers in fighting games. I believe this sort of thing is very harmful to fighting games, and I'll be using this article to explain what in particular I have against ambiguous intention, provide some examples of ambiguous intention in several fighting games, and how I think those games would be better of without such things.
First off, let me give a solid, simple definition of ambiguous intention. Basically, it is an instance in a fighting game where a restriction the game's mechanics impose on the players can be avoided via use of one or more mechanics/techniques the game provides. There are several issues with such a thing, in my opinion:
  1. It adds an artificial execution barrier to the game. Anyone playing the game at a competitive level will have to manually perform something that would otherwise (and should) be done automatically or not at all.
  2. It makes the developer's intent unclear - do they want the restriction to be respected or not?
  3. It makes the game seem harder or "deeper" than it actually is.
The first example of unambiguous developer intent that comes to my mind, not to mention one of the most generally-accepted in the fighting game community, is nicknamed "chicken guarding" in the vs. Capcom series. Normally in those games, during a short period after you initiate a dash, regardless of what direction it's in or whether it's in the air or not, you are unable to block. Clearly, the developer's intent is to make dashing punishable if predicted.
However, it is possible to instantly cancel a dash into a jump in most games in the vs. Capcom series, and after you do so, to instantly block. This overrides the previously-implied restriction about punishable dashes. Now, I have absolutely nothing against making vs. Capcom dashes punishable or unpunishable; what I do have a problem with is the ambiguous developer intent: Do the developers want dashes to be punishable or not?
If the developers do want them to be punishable, then disallow blocking even after the dash-canceled jump, or if they do not want them to be punishable, then allow blocking directly during a dash, but by no means should they require the players to go through an unnecessarily-difficult input to accomplish a competitively mandatory technique which may or may not have been intended in the first place!

The second example, and one that I think is particularly egregious, is L-canceling in Super Smash Bros. Melee. L-canceling is a "mechanic" - I am not entirely certain it is deserving of the title - that allows you to cut the period of time your character cannot move or attack following an aerial attack in half by pressing the shield/block button a few frames before you hit the ground.
With the previous example of chicken guarding in addition to the 3 problems with ambiguous developer intent I listed earlier in mind, it should be immediately obvious what the problem with L-canceling is. If the developers want aerial attacks to have x amount of landing lag, then they should leave it at that; if they want aerial attacks to have 0.5x amount of landing lag, then they should do so, but they should not require players to press an extra button for something that could easily be done automatically. Artificial "difficulty" like this makes a fighting game seem more difficult and technical than it really is, and oftentimes hides serious problems behind a fake execution barrier.

The last example I'm going to give is of "kara throwing" in the Street Fighter series. Kara throwing essentially involves using an attack that moves your character forward, but before the part of the attack that actually hurts the opponent is activated, you cancel the attack into a throw, giving the throw more range than it otherwise would have. The window of opportunity to cancel the attack into a throw is usually very small - normally about 1 or 2 frames (1/60th to 1/30th of a second).
Again, it should be obvious what the issue with kara throwing is. If the developers want certain character's throw range to be longer, then they should be longer by default, or if they want throws to be shorter, then they should prevent kara canceling, but they should not require players to perform a difficult input for something which was not only unintended in the first place (kara throwing was originally a glitch in Street Fighter 3, but is intentionally in Street Fighter 4), but which obviously could be solved with a much simpler solution. 

I've seen several arguments stating that mechanics like the ones I've listed are good things, the majority of which basically boil down to the opinion that the more buttons you have to press and the more complicated things are, the better. Personally, I believe the simpler things are, the more time and energy you can focus on the mental aspect of the game, which, in my opinion, is far deeper and more satisfying than any arbitrarily difficult "mechanic" could ever be.
It could also be argued that since no-one really complains about arbitrary difficulty and ambiguous intent, it is not a problem that needs to be solved. I believe there are a majority of reasons this is the case, the largest being that since practically all fighting games ever made have had some sort of arbitrary difficulty, with the recent ones intentionally and the older ones unintentionally, means that anyone who has played fighting games for any decent amount of time is quite used to this sort of thing by now. So yes, there is some complacency, but I think many fighting game players have merely failed to realize how deleterious ambiguous intent and arbitrary difficulty can really be, since they have had to live with it for as long as they have played fighting games. I think once more players realize how much simpler and easier to play fighting games would be without this sort of thing, the more they will warm up to the idea and let developers know about it.

I should note that I think there is a definite place for this sort of mechanic in video games; intentionally difficult single-player games like Devil May Cry and I Wanna Be The Guy thrive off this sort of thing, and many people play those sort of games just because of all the arbitrary difficulty - I'm one of them. However, I don't think arbitrary difficulty has a place in fighting games; I'm trying to fight my opponent, not the game, and the easier it is to do whatever it is I should to in a given situation, the better.
I think I should also make it clear that the presence of an arbitrary mechanic does not automatically ruin a game. I enjoy playing and watching many games that have a number of arbitrary mechanics, including the games I used as examples. All I'm saying is how much better those games would be than they already are without the arbitrarily difficult mechanics, in addition to a larger userbase, since a (somewhat correct) public notion of fighting games is that you have to spend a lot of time practicing arbitrary stuff in training mode before you can become good at them.

And you know what? Eliminating ambiguous developer intent and arbitrary difficulty would go a long way towards eliminating that notion.

Tuesday, October 23, 2012

Super Smash Bros., Combos, and You - an article on a theoretical combo system for SSB

Super Smash Bros. has something of a mixed history as far as combos go. The original SSB64 had combos galore - most of the characters had combos that could take an as-of-yet untouched opponent and KO them without a single chance to dodge or counter - the definition of a "true" combo. Super Smash Bros. Melee significantly reduced the stun the average move does to your opponent, so combos (true combos anyway) became weaker and shorter compared to SSB64.

Now, with the latest release in the SSB series - Super Smash Bros. Brawl - true combos are practically non-existent, meaning the guaranteed damage the average character in the cast can do is typically limited to one or two moves in a row. This may not sound important, but it has several ramifications:
  • Lack of combos means mistakes aren't as costly. In the typical fighting game (SSBM and SSB64 included), 2-5 mistakes might mean a stock (or the game). SSBB, on the other hand, typically lets you get away with more than a dozen mistakes before you lose.
  • The skill ceiling is significantly lowered. SSBB pros can punish mistakes no harder than intermediate players, with the possible exception of what's called "gimping" - KO'ing your opponent with relatively weak move, usually used away from the stage edge.
  • Comebacks become a lot harder, since you'll typically have to repeatedly use one-off attacks, while only a few attacks (many times just one well-placed one) from your opponent will cost you the game.
What I suggest is to give SSB a combo system/mechanic. I'm not going to describe what I have in mind for the system upfront - rather, I'll evolve it over the course of this article, which I think will lead to a better understanding of how a "true" combo system would significantly help SSB and alleviate the aforementioned issues Brawl has. So let's get started!

The first step is to see what other fighting games use. The combo mechanic you most often see in other games is this thing called canceling. Basically, canceling let's you literally cancel one move's animation frames into an entirely different move altogether. Depending upon the game, you can only cancel a move if it touches the opponent (regardless of whether or not it does damage), and for the purposes of this article, we'll assume that's the case for our combo system. Additionally, you can typically only cancel regular attacks into heavier regular attacks (think SSB's standard attack/auto combo) or special attacks.

So now we have our base mechanic. How do we apply it to SSB? Let's assume we can cancel a standard attack into a tilt attack or special attack, we can cancel a tilt attack into a smash attack or special attack, and we can cancel a smash attack into a special attack. So now, every character has this basic combo: Standard attack > tilt attack > smash attack > special attack.

This is pretty good already, but this system suffers from the same issue Brawl has: There's little - if any - room for improvement over the simple combo I just mentioned. The skill ceiling issue remains basically untouched. We need to figure out a way to allow creativity within our little combo system. What can we do to fix this problem?

We have two options: We could further extend the boundary of what can or cannot be canceled, or we can come up with another method of extending combos. The first method will simply lengthen our previous combo, while the latter's benefit will be dependent upon how versatile the introduced sub-mechanic is. We'll try the latter approach, since it helps alleviate the skill ceiling issue Brawl suffers from. So without further ado, I give you: The launcher.

Simply put, a launcher is a move that, like the name implies, launches the opponent up into the air. You can also typically cancel the launcher's animation with a jump if the launcher hurts the opponent, and for our combo system, we'll also allow launchers to be canceled into a dash, which should allow for a bit more creativity as well.

We have to integrate launchers with the little cancelling hierarchy we defined earlier now. Let's insert launchers between smash attacks and special attacks, so that our standard combo now looks like: Standard attack > tilt attack > smash attack > launcher + aerial attack or special attack.

It's not much, but this combo system is already shaping up to be relatively open-ended. However, since we've been focusing on adding new features to it, we've been left with a lot of loose ends to tie up:
  • Knockback (not to mention DI) will effect the viability of a combo - i.e, an opponent might be knocked back far enough that even if you cancel, the new move will not connect. Something needs to be done about this.
  • Hitstun - the amount of time the opponent is stunned and unable to do anything after being hit with one of your moves - will probably need to be increased on average, at least relative to Brawl. Otherwise, even if you perfectly cancel a move into another move, your opponent might recover before the second move's active frames activate.
  • It's conceivable that the combo system could possibly be abused to the point of infinite combos. We obviously can't think of all possible combos, so we should put in some sort of mechanic that will prevent combos from becoming excessively long.
Let's tackle knockback first. We obviously can't take knockback completely out of the system - it's too much a part of SSB to remove it now. So I propose that the hitlag system normally reserved for dramatic, powerful attacks be applied to all moves in the game, with about 5-10 frames of hitlag per hit. Those frames will be the "cancel window" during which you can cancel to another move and be guaranteed that it will connect - no knockback will be applied until after the cancel window has passed. Launchers will have set vertical knockback to make comboing easier, similar to Falco's shine in SSBM.

For those not familiar with the hitlag (also known as "freeze frame") system, hitlag is basically a period of time after which a move connects with an opponent during which the game is, for all intents and purposes, frozen - neither the attacker nor the defender can move during the hitlag period.

This doesn't address the tricky problem that is DI (Directional Influence), however. It's possible in SSBM and SSBB (SSB64 didn't have DI) to use DI to shift the direction in which you get launched and thus escape combos. Whether or not that's a good thing probably comes down to personal opinion, but DI is here to stay in all likelihood, so I'd prefer to design our theoretical combo system to incorporate DI.

The way I see it, the easiest way to incorporate DI into our combo system is to allow DI only after the cancel window on each hit has passed. This brings up a dilemma: What about multi-hit moves? I want to keep comboing as offense-oriented as possible, and thus have relatively few options - if any - to break out of a combo, so I think having a cancel window after each hit, but no knockback and DI until after the cancel window for the final hit has passed is a good idea. Launchers probably shouldn't be DI-able for similar reasons, so let's assume that we can't DI out of a launcher as well.

Now we only have to deal with infinite combos, something a lot of fighting games don't get right. Even the borderline combo-less SSBB had a few infinites here and there, so we'd better take extra caution with our combo system, since it's a lot easier to chain multiple moves back-to-back. Again, taking a look at what other fighting games typically do to alleviate this, I now introduce: hitstun deterioration.

In a nutshell, hitstun deterioration gradually lowers the amount of hitstun of each successive hit in a combo. Eventually, the hitstun of each hit will be practically 0, and the opponent will be able to easily escape the combo. It's obvious that hitstun deterioration could possibly limit legitimate non-infinite combos, as well as put characters with lots of multi-hit moves at a disadvantage, but it's probably the best defense against infinite combos out there right now.

Let's take a quick review of what our combo system's main mechanics are (this is a good TL;DR paragraph if you skimmed over the other parts of the article):

  • Canceling. We can cancel moves into certain other moves in this order: Standard attack > tilt attack > smash attack > launcher + aerial attack or special attack.
  • Cancel windows. There's a small window of opportunity after each hit of a move (about 5-10 frames), during which you can cancel the current move into another move, as per our canceling mechanic defined earlier. No knockback is applied (and DI is impossible) until after the cancel window is over.
  • Launchers. We can perform a launcher, which is basically a move which launches the opponent into the air with set vertical knockback, to perform an aerial combo. If the launcher connects with the opponent, you can cancel the launcher into a jump or a dash. You cannot DI out of a launcher.
  • Hitstun deterioration. The hitstun of each successive hit in a combo gradually decreases to almost 0, thus effectively preventing infinite combos. Note that this doesn't prevent a zero-to-death combo, just infinite combos.

So there you have it. We evolved a theoretical combo system around SSB's unique mechanics, ironed out some minor kinks, and even introduced a few unique mechanics of our own along the way. It's probably not perfect, and might have some errors I've overlooked while I wrote this article, but it's a simple, solid combo system that should be enjoyable by newbies and professionals alike. So that said, it's time for closing statements. :)

  • Project M, a very popular mod for SSBB, includes a combo system for Lucario very similar to the one described here. The most notable differences is that the cancel window system described here is missing, and Lucario's launcher (his up smash) does not have set knockback, meaning it's better as a standalone kill move, but somewhat hard to use at times as a launcher. Hitstun deterioration is also missing, and all his combos are DI-able as far as I know, but the system is still quite similar to the one in this article.
  • It would be feasible to make a mod for SSBB that implements our theoretical combo system, but although I'm not lacking in programming skills, I'm still quite unfamiliar with modding SSBB in general, unfortunately.
  • SSB4 will be coming out sometime next year (2013), and Masahiro Sakurai (SSB's creator) has stated that the game will be taking a "new direction" compared to previous SSB titles. Namco - who develops the popular fighting game series Tekken - is heading development of SSB4, so who knows, you might see something like this in SSB4.
Thanks for taking the time to read through this giant wall of text!

Thursday, July 19, 2012

How to use sys.meta_path with Python

I was asked on Reddit a short while ago as to how to use sys.meta_path, which is an extremely valuable tool that can be used to implement import hooks. Since it seems there's little documentation as to how to use it properly, I decided to write an example that shows basic usage of sys.meta_path. I posted the example on Reddit in the thread I linked to, but I've put it here for posterity - enjoy. :)

import sys


class VirtualModule(object):

   def hello(self):
      return 'Hello World!'


class CustomImporter(object):

   virtual_name = 'my_virtual_module'

   def find_module(self, fullname, path):
      """This method is called by Python if this class
         is on sys.path. fullname is the fully-qualified
         name of the module to look for, and path is either
         __path__ (for submodules and subpackages) or None (for
         a top-level module/package).

         Note that this method will be called every time an import
         statement is detected (or __import__ is called), before
         Python's built-in package/module-finding code kicks in."""

      if fullname ==  self.virtual_name:
      
         # As per PEP #302 (which implemented the sys.meta_path protocol),
         # if fullname is the name of a module/package that we want to
         # report as found, then we need to return a loader object.
         # In this simple example, that will just be self.

         return self

      # If we don't provide the requested module, return None, as per
      # PEP #302.

      return None

   def load_module(self, fullname):
      """This method is called by Python if CustomImporter.find_module
         does not return None. fullname is the fully-qualified name
         of the module/package that was requested."""

      if fullname != self.virtual_name:
         # Raise ImportError as per PEP #302 if the requested module/package
         # couldn't be loaded. This should never be reached in this
         # simple example, but it's included here for completeness. :)
         raise ImportError(fullname)

      # PEP#302 says to return the module if the loader object (i.e,
      # this class) successfully loaded the module.
      # Note that a regular class works just fine as a module.
      return VirtualModule()


if __name__ == '__main__':

   # Add our import hook to sys.meta_path
   sys.meta_path.append(CustomImporter())

   # Let's use our import hook
   import my_virtual_module
   print my_virtual_module.hello()

Note: The original PEP that defined the sys.meta_path protocol is PEP #302, which you can read here.

Saturday, July 14, 2012

Reverse-engineering LEGO Racers 1 - part 1

First off, a brief description of LEGO Racers 1: It basically was a racing game released back in 1999 (and then re-released in 2001) where you could make your own car (and driver) out of LEGO bricks and then race it against half-a-dozen or so AI cars or a friend, on one of about two dozen tracks. Sounds fun, right? It is.



Sadly, since the game was released so long ago, it can be difficult to run it on a modern OS - the 1999 release of the game had DRM that required the disk, for example - not to mention there's quite a bit of dummied-out content (several shortcuts are missing, most famously from the Knightmare-athon track) that I and probably several others would love to play around with and modify. And that's why I've decided to write a drop-in replacement for the LEGO Racers 1 game engine.

It's not a new idea - I can bring up forum threads from up to 2 years ago of people attempting to mod LEGO Racers 1. That being said, these people are trying to mod the game itself, not create a replacement for LEGO Racers 1's game engine. I want to create a game engine instead of attempting to mod the game itself for several reasons:
  • A mod of the game still would have issues with the DRM and compatibility issues I previously mentioned; one would still need the original game to play the mod.
  • A mod of the game would not be able to add new content without removing existing content; I doubt, for instance, you could add new circuits, bricks, chassis, or piece sets (you unlocked the pieces of each bosses car when you beat them) without removing existing content.
  • A mod of the game would still be subject to the limitations of the original game engine - AI cars still wouldn't follow shortcuts, the AI behavior itself couldn't be changed, no new racing modes could be added, racing with more than 2 human players wouldn't be possible (and even then, you'd need a joystick), etc. In other words, only content would be moddable, not game logic.
There would be many advantages to making a game engine as well:
  • Not only would only the data files from the original game be required to play, but it would be feasible to create a replacement for the original data files as well, so you wouldn't even need the original game to play (ala PrBoom + freedoom).
  • A replacement for LEGO Racers 1's game engine would allow everything to be moddable - powerups, tracks, circuits, AI behavior (imagine the AI being a script the game engine runs instead of being part of the engine itself), bricks, piece sets, cutscenes, animations - everything.
  • Making a replacement game engine instead of modding the original game makes modding much easier and more approachable to a new modder.
Right now, I intend to make the engine open-source (under the Apache License 2.0, probably), and host it on GitHub, to make it more accessible to potential developers. If you'd like to help out (that said, I haven't started yet), let me know. :) I'll try to keep updating my blog as progress on reverse-engineering LEGO Racers 1's data formats is made.

Friday, July 13, 2012

Minetest Triforce

In case you're not familiar with it, Minetest is basically a free, open-source clone of Minecraft, plus some new stuff like Lua mod support. Anyway, I made a very large Triforce on gameboom's mt1.gameboom.net (port 30000) Minetest server some time ago, and this is the result:

Daytime


Nighttime