Invitation Only

I have had problems with spammers in the past. It is so annoying to be constantly inundated with robotic registrations requests. I guess the good news is that they are not in the site posting links for male enhancements.

In any event, as no one ever noticed, this website used to have a phpBB forum. It was a bit clunky and didn’t quite look like the blog, but it worked and had tons of functionality. Recently, however, I decided to migrate to bbPress. (The migration tool wasn’t great and I had to install a plug-in to customize the colors, because I didn’t feel like hassling with CSS, but I got everything over and it’s operational.) The reason was because my hosting provider only allows two DBs for my account level and I wanted one of them for something else. I didn’t know if bbPress would just use the same DB as WordPress, but turns out that it does. Win!

Anyway, for the past few years I’ve been wondering why the phpBB registration has been constantly hammered by spammers while the blog registration has not. I finally figured it out; my blog doesn’t have a registration!

I thought about opening the registration, but after doing a bunch of research on anti-spam plug-ins and moderation tools, I decided that invitation only is the best. Perhaps one day this blog will be large enough that I’ll want to invest in all that, but for the time being, anyone who wants in will just need to contact me and request an invitation. For what it’s worth I’m only giving invitations to people I know. Sometimes tiny communities are best.

No cs234 Project

It was with a mix of disappointment and relief that I learned cs234, the final course for my Artificial Intelligence Graduate Certificate from Stanford, cancelled the project for this quarter. With the course going fully online due to the pandemic, the rational was to give everyone a bit of a break. That is perfectly reasonable given the work projects often entail, but it would have been pretty cool.

As such, development is once again suspended. (These Stanford courses are a lot of work, and there is a family and a job.) During the December sprint, however, I am happy to say that quite a bit of progress was made:

2020 GitHub Contributions
2020 GitHub Contributions
  1. A line of code was written – Just doing anything after 4 years is an accomplishment.
  2. Automated combat with enhanced messaging and logging – When I do get around to building a deep RL model to train the agents, this will be handy.
  3. Created the wizard class with wizard spells, including touch spell attacks – This one rounds out the fighters, clerics and rouges. I won’t be adding any new classes for a while.
  4. Group combat – Previously it was the ‘hero’ versus the monsters, but now two groups of combatants can fight each other.
  5. Charging, flanking and cover – These add a little more dynamic to the combat.
  6. Ferocity – Orcs just became much more challenging.
  7. Fixed a bunch of bugs – Always a decent idea.

I’ll try to pick it up again in April, but we have to see how that goes.

A line of code has been written

The title’s deliberately passive voice is intended to comically understate the fact that it has been four years since I last worked on this project. Four years! I previously wrote about the delay, but the long story short is that life got busy and I got distracted with, arguably, much more important things. That being said, I am giving it another go. The renewed motivation comes from an unlikely source: Stanford University.

Over the past several years I have become quite passionate about AI, taking a number if different MOOCs, reading various book and pursuing some personal projects to explore the domain and learn the technology. One day in late 2018, gazing out of my office window at PARC, I spied the spire at the top of Hoover Tower and thought to myself, “I bet they have got some AI classes over there.”

Turns out they do. More specifically, turns out they have a Graduate Certificate in AI which offers a 4-course, 16-unit program of master’s-level instruction in AI. What could be better than that? A statement of motivation and a couple transcripts later, I was in. With a family and demanding full-time job I knew that pursuing graduate coursework would be challenging, but if I took only one course at a time, how hard could it be?

I quickly discovered that it could be very, very hard. Deep Learning (cs230) with Prof. Andrew Ng was the first course I took, which was probably a good choice. It was not a ton of work, until the final project, but the midterm was shockingly difficult. AI Principals and Techniques (cs221) is the only required course for the Certificate, so I took that next. It wasn’t too difficult, and I was more prepared for the midterm, but it was a lot of work and our final project was challenging. Then I took Machine Learning (cs229), again with Prof. Ng. It is notoriously one of the most difficult courses in the department and it lived up to its reputation. It was also an amazing amount of work and really tested my family life, but I survived that, too. In fact, we all did.

So what is this all about? For my last class I am signed up to take Reinforcement Learning (cs234) with Prof. Emma Brunskill. What does that have to do with Mortal Wayfare? Well, like all the courses, there is a final project. I therefore thought it could be really cool, for the final project, to implement RL within the game to ‘teach’ the actors (i.e. monsters and NPCs) to fight optimally. You can tell from game play that most RPGs use a simple rules-based decision engines to control enemies during combat. With a complex D&D-based system, however, constructing those rules can be complicated and the end result is often flat. I am curious to know what sort of dynamic and exciting combat I might be able to get by leveraging the materials from the course. To be able to do that I need to get the game back in working order as well as build a mechanism for fully-automated, repeating combat. After only a week, which I’m chronicling on Twitter, I am getting closer, but we will see how it goes. The course starts in January, so I am running out of time. Whatever happens, however, I will report back here.

In any event, unwilling to stop after course number four, I have already submitted my application for the MSCS program. Wish me luck!

I hate spammers

It’s been a very long time (over 3 years!) since I last wrote a line of code for this project, so my hiatus was obviously significantly extended. I’ll have more on that later, but I’ve decided once again to try to get back at it.

The first thing I did was log into the forum as an admin, only to find over 6272 registration requests. I’m sure that 100% of them are spam. Casually scanning the list, I’m seeing emails like toniagx18@ryoichi.hiroyuki73.kiesag.xyz and n.x.g.s.oft.wa.resolu.ti.o.n.s.co.m@gmail.com. These are not real people. I’ve been getting ~60 requests a day. ~44% are from a “.xyz” domain and ~39% are from “.ru”.

A long time ago (I think it was October 2018), I implemented the phpBB Q&A plugin spambot countermeasure. I choose a question that would not generate an answer if run on Google and would require a small amount of digging on the forum. Well, apparently sometime in July 2019 the spammers actually went to the effort of digging out the answer and programming it into their spambots.

I’ve now effectively disabled registration requests by requests by removing the answer to the Q&A, and it was easy enough to delete all of the requests from the admin panel, but I’m going to need to figure out a way to stop this. CAPTCHAs haven’t worked for a while. Email verification would probably help a ton, but I’d like a way to control registrations after the email is verified.

Also, I’m getting a slew of failed login attempt notifications as spammers try to brute force me admin password (I’m blocking IPs after 3 failure attempts) and and I still getting email spam even after changing the configuration to require being logged into email the admin (they might be guessing the email address).

This is going to require some thinking and research. I hate these people.

Holy hiatus

I’m sure nobody noticed because nobody is actually following this blog, which is fine. That being said, I just looked up my last commit, which was Oct 31th, 2016 – 671 days ago! During this time I have been busy with full-time employment, taking classes in ML and AI, playing around with deep learning, volunteering for a fantastic AI conference, running the books and making a presentation for an amazing non-profit and otherwise life.

In the back of my mind, however, there has always been Mortal Wayfare. I’ve fantasized about finding time to do everything from creating the wizard class (there are already fighters, clerics and rogues) to using reinforcement learning to ‘teach’ the enemies and NPCs policies for optimal decision-making. So why this post now?

Yesterday, in a burst of get-it-done-idness, I fixed the MW email and upgraded the phpBB to v3.2.2. It still needs some tweaks, but I’m now going to try to figure out a system to deflect the relentless spammers, who, for the moment, are the only visitors to this site. Then I’m going to download the repo and try to figure out a plan to, painful inch by inch, move this project forward until, one day, it’s the most amazing retro 2D Android turn-based RPG on planet Earth. If not, I hope to at least have something that is playable. That sounds like a lot, but actually, I don’t think I’m too far off.

Wish me luck, nobody.

One cannot always decorate that cake

I was very excited about the Decorator Pattern, right up until I wasn’t.

Being new to design patterns, and OO programing, and Java, and programming in general, the Decorator Pattern looked like an effective (and entertaining) solution to a particular challenge: applying effects (i.e. feats, buffs, equipment bonuses) to actors in order to change their properties (i.e. ability scores, to hit, AC). Also known as a ‘Wrapper’, this pattern “… allows behavior to be added to an individual object… without affecting the behavior of other objects from the same class.”

Perfect! So, if the hero casts Bless, for example, just wrap her in a Decorator like this:

// Abstract decorator class for Hero
public abstract class HeroDecorator implements HeroInterface {

    protected final Hero decoratedHero;

    public HeroDecorator(Hero hero) {
        this.decoratedHero = hero;
    }

    // Implement interface method
    public int getToHit() {
        return decoratedHero.getToHit();
    }
}

// Decorator wraps the Hero in a Bless spell
class Bless extends HeroDecorator {

    public Bless(Hero hero) {
        super(hero);
    }

    // Overriding method defined in abstract superclass
    public int getToHit() {
        return super.getToHit() + 1; // +1 to hit bonus from spell
    }
}

To ‘Bless’ the hero, just do this: hero = new Bless(hero);. Now hero.getToHit() will return the original ‘to hit’ with a +1 bonus. Done! If the hero picks up a magic sword that adds another +1 to ‘to hit’, hero = new MagicSword(hero); where class MagicSword extends HeroDecorator. If the hero becomes cursed, and takes a penalty on ‘to hit’, you can still do hero = new Curse(hero);. Decorators can also be stacked, so you can just keep wrapping and wrapping. hero = new Bless(new MagicSword(new Curse(hero))); will work.

There are reasons, however, why all of this is a bad idea.

Removing the frosting

The first problem with the Decorator Pattern is that once you wrap an object you cannot unwrap it, at least not without a hack. The Bless spell above is eventually going to expire, at which point the hero no longer gets the bonus, so what do you do?

One option is to implement a way to ‘deactivate’ the decoration. Perhaps the Decorator itself would have a timer that, after a certain duration, would stop adding the bonus. Or perhaps you could implement a method enabling the toggle of a boolean active; within the Decorator. Regardless, this is going to be a terrible approach as the object will continually grow in size, forever, as it’s wrapped, re-wrapped and wrapped again. Imagine what your hero will look like by level 20.

Generally, you cannot remove the wrapping. According to this amazing post on StackOverflow, “You cannot un-decorate a function. (There are hacks to create decorators that can be removed, but nobody uses them.) So once a function is decorated, it’s decorated for all the code.” The ‘hack’ being referred to here essentially involves treating the Decorators like a Linked List: each Decorator keeps track of both the immediately outer Decorator, in addition to the immediately inner Decorator, so that when it expires it can ‘decouple’ itself by linking the two of them.

Keeping track of the ingredients

Nevertheless, even if you implement the hack for ‘decoupling’ Decorators you are probably going to still have the headache of keeping track of all of the decorated methods. Notice the HeroInterface above. It looks like this:

public interface HeroInterface {

    public int getToHit(); // Returns d20 to hit roll
}

It exists to make sure that any decorated method gets ‘passed through’ all of the layers of Decorators so it can end up at the base object. This means that every Decorator, even those that do not affect ‘to hit’ (e.g. override public int getToHit()), must implement the method and pass along the functionality to the super method, like public int getToHit() { return super.getToHit(); }. Furthermore, every decorated method needs to be in the interface, which could end up looking like this:

public interface HeroInterface {

    public int getToHit(); // Returns d20 to hit roll
    public int getAC(); // Returns AC
    public int getAbility(Abilities ability); // Returns Str, Int, etc.
    public int getSavingThrow(Saves save); // Returns saving throw
    // and on, and on, and on...
}

Every Decorator will then have to implement every one of these methods, which will get ugly. Add a decorated method and you’ll have to then update every Decorator. According to Michael Feldman, “For longer classes, a programmer must choose the lesser of two evils: implement many wrapper methods and keep the type of decorated object or maintain a simple decorator implementation and sacrifice retaining the decorated object type.” In other words: hassle.

Remarkably, however, this, too, can be ‘hacked’. This StackOverflow question describes the exact problem of a implementing an interface for a class with lots of methods to decorate. My answer involves eliminating the interface by implementing the bytecode generation library, CGLIB. Using a proxy solution Decorators are then able to implement just the methods they want to override while simply passing through everything else. There’s a performance hit, but it works. You can try my code for yourself.

Eat ice cream instead

While with a Linked List style Decorator and a bytecode generation library proxy solution you could, in the end, decorate your cake and eat it, too (you’re welcome), there’s a better way.

As helpfully pointed out in a StackOverflow chat room, Anubian Noob suggested storing the ‘to hit’ bonus (and all other parameters that could be affected by an effect) in the base class, loading all of the effects into a list and simply iterating through all of them during updates. My Bless class now looks something like this:

public class Bless extends Effects {

    private Actor actor;

    public Bless(Actor actor) {
        this.actor = actor;
    }

    @Override
    public update() {
        actor.toHit += 1;
    }
}

When the Bless is complete, just remove it from List<Effects> effects = new ArrayList<>();. Easy. Alternatively, which is what I chose to do, you can iterate through the collection of Effects whenever a value, such as ‘to hit’, is required. It looks something like this:

public class Hero {

    private List<Effects> effects = new ArrayList<>();
    private int toHitBonus = 0;
    private Random rand = new Random();

    public int getToHit() {
        for (Effects effect : effects) effect.updateValues();
        return rand.nextInt(20) + 1 + toHitBonus;
    }
}

As one of the design patterns laid out in the Gang of Four’s famous tome, the Decorator Pattern must certainly have important utility. At least for me, however, despite no lack of effort, I decided that it just wasn’t helpful in this case.

Building the game engine from scratch

In October ’14 I attended a “Share Your Projects: Lightning Talks” event where mobile developers demoed their personal projects. While chatting beforehand someone asked me what ‘engine’ I was using to develop my game. As I was looking confused, he offered, “Unity?” along with a couple other suggestions. I had no idea what he was talking about.

Demonstrating a very early Alpha version for a particularly interested individual
Demonstrating a very early Alpha version for a particularly interested individual

A game engine is, I learned, simply “a software framework designed for the creation and development of video games.” They exist for Android and most everything else. Core functionality, such as UI, rendering, physics, AI, logic, etc., are all already provided, obviating the need to reinvent any wheels. With a multitude of different off-the-shelf game engines available, why write your own? According to Michael Kissner, “Don’t, if you can avoid it.”

Michael then goes on, contrary to his own advice, to write a four-part series on building game engines, because, as he points out, some people might “want to learn how an engine works.” This was my motivation from the beginning. (Although, frankly, I didn’t know any better.) For anyone else interested in doing likewise, there is a myriad of instructive blog posts (I found this one particularly helpful) and I would highly recommend Game Programming Patterns. Perhaps I’ll eventually post some helpful tips on this blog.

In any event, the answer to the question asked of me at the Lightening Talk turned out to be, “I’m writing directly to the Canvas using my own engine.” Today I stumbled across this Quora answer to What is considered as the most difficult level in programming?: “I’d say developing a game engine.” I’m not sure if she’s right, but it’s enjoyable to hear.

Formula for computing ability modifiers

Here’s something that should interest… almost no one… but I’m sharing nonetheless. Since the game is based on ability scores, I need to compute an ability modifier for a given score. One could brute force it with a table, but I think the following is more elegant:

private static int abilityModifer(int abilityScore) {
    return (abilityScore / 2 - 5);
}

Given an integer ability score, this Java method returns an integer ability modifier. Easy.

It might be helpful to note that while (x / 2) – 5 is equivalent to (x – 10) / 2, if you go with the latter, which is how I started, the code gets a little more complicated:

private static int abilityModifer(int abilityScore) {
 return (int) Math.floor((float) (abilityScore - 10) / 2);
}

The problem is with the rounding. The trick here, that took me no small amount of time to figure out, is that you need to cast the (abilityScore - 10) / 2 argument to a float before passing it through Math.floor(). If not, the negative modifiers aren’t calculated correctly because the argument gets implicitly cast to an int which, for ability scores less than 10, rounds towards zero, which is the wrong direction. Math.floor() will round the float toward negative infinity, which is what you want.

In the beginning, there was BASIC…

History

Like many nerdy youth, I spent a lot of time on my computer. Like many who were were youths in the ’80s, that computer was an Apple ][+. (Thank you, mom and dad, for chipping in so that I didn’t end up with a TRS80.) I had the RAM expansion board for a full 64K along with dual 5½” floppies that I modified with hardware switches to toggle write protection.

Most importantly, however, I learned BASIC and devoted considerable effort to writing software, most notably a program I called Function Plot (a utility that graphed functions in Cartesian and Polar coordinates) and games. Being a Dungeons & Dragons fanatic (who wasn’t, right?) and loving the Ultima and Wizardry series, those games were predominantly 2D RPGs. (The logic was in BASIC but I taught myself assembly in order to develop subroutines to quickly render the graphics.)

Apple ][+ Assembly
Apple ][+ Assembly

At one point in high school I learned Pascal, in college I then suffered for four years with Lisp (please don’t explain to me how awesome it is) and in my first job out of school I tinkered with the x486 BIOS and device drivers. I spent some time playing around with Borland C as well, although I never made much progress with that.

Motivation

Then I moved to the dark side (business school) and my days of writing code were behind me. My career has been exclusively in computers and the internet, and I’ve worked closely with software developers, but I didn’t sling the code myself. (Albeit recently I’ve done a considerable amount of scripting in Ruby and R.) Over the years as I followed the evolution of software development I often wondered if I still had the chops. So a few years ago, I decided to find out.

World of Warcraft
World of Warcraft

The idea was to build, once again, a 2D RPG. No single developer could ever build anything approaching the scale of a modern RPG, but perhaps a lone programmer could put together something “old school.” Since mobile was ‘hot’ and smaller devices seemed like they might lend themselves better to a slow, low-res 2D game, and Java was ‘everywhere’, I decided to go with Android. Having never developed in Java, or OO for that matter, or on any framework, in March 2013 I nevertheless signed myself up for a full-day “Introduction to Android” boot camp taught by the amazing Nathan Esquenazi and Tim Lee, founders of CodePath.

That was a very depressing day.

I understood nothing and left convinced that there was no way this would ever happen. Yet in my minuscule amount of free time I persisted. Nathan and Tim were nothing short of fantastic in coaching me along the way, for no other reason than their love for teaching people to write code. My Stack Overflow page views grew. (How did anyone ever do anything without SO?) My wife was amazingly supportive, as always. Teeny, tiny pieces started coming together bit by bit (pun intended) until one day, finally, I got “it.”

Perseverance

Today, 10+k lines of code later, I think I can legitimately say that I have what is beginning to approach a real game, that people might actually be able to play. It may not be coming soon, or perhaps even ever at this rate, but in a relatively bug-free manner you can create a character, move around, do some stuff, kill a few monsters and get wiped out yourself. Fun!

Mortal Wayfare is not publicly available, but this website was put together a couple days ago to share (the very slow) progress and invite a few patient, understanding friends to Alpha test. Check out the Forum and come back periodically for updates. Perhaps one day we’ll meet in the Google Play Store.