Why your Smash Bros for Switch dream roster might be completely wrong

Now that the hype generated from the new Smash trailer shown during March 8th’s Nintendo Direct has quieted from a barbaric cry to at least a quiet roar, we’re starting to see the first evidence of mainstream “dream rosters.” From the ridiculous to the (slightly) more subtle, everyone has some semblance of who they want to see in the new Smash game.

While I’m not one to crush people’s dream[roster]s, I think there’s something people may want to consider when making their lists: this new game is apparently not developed by Bandai Namco. The end of the trailer credited Hal Laboratory (the developer of Smash64 through Brawl) and Nintendo for the game, with absolutely no mention of Bandai Namco.

The good news about this announcement is that it’s almost irrefutable evidence that this new Smash is not a remake of Smash Bros for 3DS/Wii U, or Sm4sh as it’s more commonly referred to, but a completely new game. This is also given some credence by a tweet from long-time director of Smash, Masahiro Sakurai.

That means that the other, not probably as good, news is this likely means Bandai Namco characters will be out of the equation, doing more damage to dream roster brackets than Duke losing to a 15-seed in March Madness.

The first question you’re likely asking is: what does that mean for returning characters? Well, firstly, since the Xenoblade IP is owned by Nintendo and Bandai Namco, Shulk would be out. Secondly, Bandai Namco owns the rights to Pac Man, meaning Pac Man would also be out. Furthermore, without the pull and financial backing of both companies, we may see characters from third parties such as Capcom and Square Enix leave as well, meaning Cloud, Ryu, and Megaman may be out. It would be unlikely that the partnership between Sega and Nintendo would be in jeopardy here, since it’s been confirmed since Brawl, but if Microsoft buys Sega, as it has looked into in the past, that could mean the loss of Sonic and Bayonetta (doubtful, but a possibility).

Moving on to the elusive “new” roster additions, no Bandai Namco means, well, firstly since I know you’re thinking it, no Goku. Let’s just get that right on the table. Bandai Namco owns the property for Dragonball and all of its offshoots and sequels as far as game-making goes, so any character from that series is out basically (not that I don’t already think it’d be a ridiculous conflict of interest for Nintendo). They also own the rights to Souls, Katamari, Naruto, Soulcalibur, DigDug, Digimon (which is way more common than I thought), and Tekken. Anything from those IP’s would be a far shot as it is, but are now basically out.

Hopefully this doesn’t shake up the community’s expectations, but I imagine this partner departure means the roster will likely lose some favorite faces. I predict the roster may end up being smaller (pre-DLC) than the current one for WiiU/3DS, and we may see the loss of some of the extra-weight characters such as Dark Pit and Lucina (extra skins maybe?), or less popular niche characters like Wii Fit Trainer and the Mii characters.

What are your thoughts? Does this change your expectations or dream roster? I’d love to hear what your dream roster is, and if this alters your opinion.



This is completely unrelated to programming, but I wanted to share a poem I wrote a while back about being in the throes of an abusive relationship.


Crafting understanding on a cardboard frame;
Exchanging pleasant memories melodically.
Darker thoughts are dormant, insidious shame,
Whose secret woes will show asymptotically.

Peaceful interactions are all that play out;
Natural conversation, no misplaced complaints.
Crafty, crooked hider with no mouth may shout-
Revealed to have a face when removed of restraints.

A cheeky smile, a kiss turns frown into chuckles,
Each friend taking turns to ease any conflict.
The luring, lurking shadow whitens its knuckles
And bores teeth of homunculus derelict.

Silent war is had with no resolution;
Pretty thoughts are like icing to hide rotten cake.
Meanwhile the creature grows much more hideous,
Gnawing on tension like a gristly steak.

Finally the monster comes out of hiding,
Slashing and biting inject clairvoyant venoms;
Like bee to her victim, the barb left behind,
The poison to future relationships benumbs.

This is all that I finished of the poem before I ended that awful relationship, but it describes fully the dual roles of what I thought was an appropriate and decent situation. The “homunculus” shadow hiding behind the enticing personification of the relationship; the unspoken war between the two of us; her Hyde and my Tess.

Equal parts self-doubt and poor judgment let that last longer than I’d like to admit, but for now it is important to look back at it and revisit those feelings that I managed to bury so deep and for so long.

The Early Riser

It’s a common -ism in game development that you either make or you play. For those who follow this religiously, you come home from your day thing, whatever it is, and you either sit down and dev, or you grab a controller. And this goes on for long periods, often a week, month, or several months before you hang one up for the other.

For some, though, just one is not enough. And out of this stems the rarest of the game devs – the Early Riser. The Early Riser starts his or her day at 4-5am, when the strange majority of devs are just ending their days. They slump out of bed before dawn, throw a pot of coffee on, and start up their workstation.

What seems to be a rare show of healthy productivity only hides the grab at “having it all,” devving and gaming without exclusivity. You dev, then you work, then you game, then you sleep (often not enough, because the draw of development wakes you early and the draw of play keeps you up late).

Here’s to you, Early Riser, may you always have it all.

Debugged: A Short Story

Alright, let’s open the F12 Developer Tools, inspect this element and see what function this is calling. Found it. AJAX call, returns a JSON string. ASPX file. Here’s what I’m looking for. Why does it return the formatted email here? Why not use a preset? No time to redo this, have to find the source of this error.

Why is nothing sending with my email?

Parse JSON string, looks good. Debug mode, what are my variables set to when this is called? Everything checks out. No errors. No empty objects.

I take another sip of the now-cold black coffee sitting on top of a pile of orange sticky notes, the bottom of which is an exact circle perfectly fit into the center of the square note. It’s so perfect, its radius matches half the length of one side of the square, to the millimeter.

It’s an error in the Javascript. Look at each variable. Look at the syntax. Is the AJAX call written correctly?

I’m wasting my time here, the error has to be in the code behind.

I take my glasses off, wipe them clean. Spray them, wipe them again. I blow the dust out of my keyboard. The control feels good. There are no bugs in my physical interaction, the code in my brain allows me to interact with these objects and control their organization, their appearance, their usefulness, no debugging required.

Oh, maybe it’s a problem with the front end, it’s only printing the message, not sending it over the AJAX call. Okay no that’s not it, I can see the JSON message in the callback clearly. I go to the definition of a few object in the code behind. I go to the Javascript, recheck my variables.

Version control. Who touched this last?

I made it. I don’t even remember my logic. I’m wasting my time. I lean back in my chair, indicating subconsciously that this is no longer under my control. It’s almost as if the last vertebrae hitting the back of the chair lets out a faint sound, a tiny cry of helplessness.

I bet it’s a user error. I bet it’s a problem with the server. I bet, maybe, the processor is running so quickly it’s occupying the message after the send request is done. None of those are reasonable assumptions.

Open Fiddler, check every call, pore over every RAW, JSON, Web View, it’s here somewhere.

Why did I choose this awful profession? I have no control. Why is this issue even relevant? The user can just copy and paste the contents and send it that way, this tool is just easier. But it isn’t easier for me.

Front end.

I am no detective, why should I be confined to investigate constantly and never find the culprit? At least a detective can accuse, point at something and have others ring in agreement. At least there is semantic leeway, objective consideration, here there is only right, wrong, 1, 0, output, error.


Seriously, I am running in circles for a half-hour to fix something so MENIAL. It’s as if I got a degree in failure, to be imprisoned in a mindless maze of haystacks and needles, each needle smaller and rustier than the last, leaving your finger bloody every time you find it.

Javascript. Line by line now.

Why work even? The forty years I spend doing this will amount to a cycle of small promotions and an endless quest for the next vacation or weekend.

Line 5. Even the strings. Especially look at the strings.

What even is the point of living? You learn a skill that makes you miserable, you use it for half your life, you explore after you’ve lost your fitness for exploration, you die.




I notice I haven’t eaten in six hours. Why eat, though? What’s the point if


“Messagee,” inside a string, blended like lettuce in a salad, now standing out like the last crouton; I can notice nothing else.

I sit up, coffee cup to its rightful place, glasses back up my nose, pull keyboard to center. Click. Backspace. Ctrl+s. Smirk. Alt+Tab. Shift+F5. Shake my head left and right as the smirk grows. Test the feature. Bug is gone. Alt+Tab. Rebuild Solution. Check out. Check in. It’s a full-blown smile now.



Faulkner said that time is the “reducto absurdum of all human experience, a long diminishing parade in the mind unbroken.” So, basically, the timeframe of my negligence to this blog is absurd, and completely ignorable.

Stay tuned.

Building Something Cool Chapter 3: “If You Love Something, Set It Free”

March 2015.

On March 2nd, Unreal Engine announced it was becoming free.  Along with that, Unreal released version 4.7 of its Unreal Engine software.  It was a huge day for our little capstone project.  Everything seemed to be clicking into place.  Not only were we knocking out a surplus of tasks early on, but we were also on the forefront of a game design MOVEMENT.  We were ecstatic.

Then we read the release notes.  This epic update was not just changing the game design mantra and buffing an already polished design – it also changed a whole slew of inbuilt function headers, names, and so on.  This is good and all, but more than half of our c++ classes and functions had to be re-written or updated, which was a huge setback.

Sam, Isaac, and I toiled over the hundreds of lines of code we had all already written in an effort to fully integrate 4.7.  We deleted classes, pieced together broken function calls, renamed dozens of outdated references, and debugged our butts off.  Though Kurt and Julia were able to continue work without many interruptions from the update, by the time Isaac, Sam, and I were done updating…

April 2015.

… well, you see where I’m going with this.  After a sprinting start in the first week of March, I had stumbled on the usable actor class I was supposed to implement.  Isaac had only finished half of the animations we needed and still had not started testing out the VR mode. Of course, Sam was still popping out c++ classes like it was his job (it kind of was, but that’s a different story).  However, he was now doing so at an admittedly frustrating pace, due to having to relearn many of the class/function declarations he had already learned, along with having to adapt all of the new stuff into an entirely new architecture (we were now using mostly blueprints).

Beyond the setback of the update, we were hurting in some other implementation fields.  Kurt was struggling with the incredibly complex art of AI in Unreal Engine (for which debugging is often impossibly abstract).  Sam was being crammed with not only his work, but most of the overflow of other group members’ issues.  Julia was having to make some hard design choices, especially when deciding which elements were superfluous and which were essential.  As for me, I had no attached sounds, no player market to speak of, and the usable actor class (I finished a couple weeks into April) was proving to be much less useful than previously thought.

And to top all of this off, STEM backed out of their promise to have developer kits out before the middle of March.  The due date was two or three weeks away, and all of the sudden we had to explain to our professor that an integral part of our design, hand motion, was no longer viable.  We had to scrap a huge piece of our user experience, which upset several of the members of the group immensely.

We were in a nuclear meltdown.  A month and a half ago, we were at optimal cruising speed, and now we were in atmospheric reentry with a malfunctioning parachute.

However, we knew what we had to do – plug on and get this thing finished, come hell or high-water.

Building Something Cool Chapter 2: Dev Days

In this installment of Building Something Cool, I will be going over the first few months of development of our project, and I will discuss the challenges we faced while learning and growing accustomed to the Unreal Engine interface.

image courtesy of Zak Parrish, youtube.com (unreal engine's channel)
Image Courtesy of Unreal’s Zak Parrish

December 2014.

After getting our design fleshed out, it was time to get started with the real work for the project.  Knowing the sheer amount of stuff we wanted to have in our game, we decided to start early.  Before the semester had come to a close, we had already tested our peripheral, the Oculus Rift, and had a github set up for our project.  There was an uphill battle ahead of us, but we took early steps to ensure that we were up to speed before we started our climb.

January 2015.

Having made a repository for Angelis, set up a virtual reality lab on campus (with some badass new graphics cards), and hammered out our design, it was time to write some code.

Cue the classic Scooby-Doo line, “let’s split up, gang.”  Sam, Kurt, and I began work on the C++ classes.  Julia started doing some level design.  Kurt also began work on AI research.  And, Isaac began hammering out some code for the character animations.

I was tasked with creating a usable actor class.  For this, I needed to make it so that we could form actions around specific objects in the game world.  If you clicked on a spawner node, for example, a weapon would spawn close by (or in your inventory).  If you walked in front of an elevator, the up or down arrows would light up when the reticle was over, and the elevatory would move correspondingly.  This was also important for several character interactions, such as picking up a weapon or handing a weapon to an ally.

Kurt was working on AI classes.  For this, he needed to create a diagram of ways the AI interacted with the world.  This involved creating a state diagram, with four super-states – rest, patrol, alert, and attack – and many sub-states and nodes.  Also, he had to manually create cover nodes for the AI to interact with.

Sam had reign over all of the character and weapon classes.  He would gather attributes from our shared Trello page, then file them accordingly into classes.  After this, he would tie them in with character or weapon blueprints and get them all working in one of our test maps.

Julia, after reading up on several design books, was working diligently on creating a captivating level.  After creating one based on her original design, she made the revelation that it was entirely too large for use in the game mode we had in mind, and so she made up a new, more relevant level model.

Isaac was making slow-and-steady strides in the animations department.  Finding assets and applying them to our current characters and weapons was his first task, most of which were readily available in the Unreal Engine asset store.

A couple weeks in, and we had already made strides that some groups weren’t even thinking about yet.

February 2015.

Barring some early midterms, most of us were putting hefty hours into the project every week.  With the semester beginning to fly by, we knew that persistence was paramount to finishing on time.

I had compiled a comprehensive list of game sounds, as well as finalized my economy formulas; I was falling behind on the usable actor task, but I made some real headway on sound assets.  Kurt and Sam ground out several working test levels and characters.  Isaac found some useful information about an upcoming VR mode for Unreal.  And, Julia finished her level entrance.

Things were shaping up fast and we were ahead… but that wouldn’t last.

The Ten Rules of Gaming

Here is a little story I wrote when I was a junior in high school in 2009.  It’s one part hilarious, two parts relevant, and many parts facetious.

I thought that this would be something funny to write about. So here are my ten rules of gaming.

Rule number one-

We do not talk about gaming… to attractive women. Gaming, while it may be the ultimate form of entertainment, is also the ultimate lady repellent.

Fight club ref. Solid start.

Rule number two-

The noob is a subgenre of human that is the scum of civilization and deserves to be crushed in all situations.

Amen, little me.

Rule number three-

Any gun that is cool and/or useful in a first person shooter is not to be used EVER in online play. Those who use such weapons are dirty nooblets and will be trolled. such weapons include, but are not limited to:

the noob tube (CoD)

the sword (halo)

the sniper rifle (any fps)

the chainsaw feature (Gears)

Rule number four-

Screen-watching results in nut-punching. Don’t do it.

Rule number five-

If you can’t tell me what any of these abbreviations mean, you need to gtfo:








Rule number six-

Just as being social requires consuming copious amounts of alcohol, gaming requires consuming large amounts of mountain dew and sometimes energy drinks or dr pepper.

Or alcohol.

Rule number seven-

The C stick is not a valid instrument in super smash. This is the most sacred rule of gaming. Violations of Rule seven result in severe punishment.

Rule number eight-

Trolling is not cool. It is off-limits unless trolling a noob or a troll.

Rule number nine-

Anyone who humps people they kill in Halo is an 11-year-old nooblet vagina.

Rule number ten-

Achievement gamers are NOT real gamers. Achievements are cool but real gamers game for the experience, not for the experience points.

And that’s my list of the ten rules of gaming.

Well, there it is.  Little me… err… skinny me wasn’t playing around with that writing style.  I have to say, getting serious on the last rule kind of brought all of the elements together (and it is definitely something I haven’t changed my attitude on).  I hope you enjoyed this old list of gaming guidelines.  I know I did.

Building Something Cool: A Long First Chapter


The following is a history of my own experience with making a shooter centered around VR technology.  It started out as a capstone project, and has become a recurring source of work and experience.  This post is about the capstone part, but will be continued with many chapters that go over my (along with some of my team’s) current struggles and accomplishments in continued work on this project.

September 2014.

As we all sit in Capstone class discussing our collective worry about what we could do that might be meaningful, I have no hesitance.  I have known what I wanted to accomplish since the day I chose Computer Science as my major – to make a game.

The professor walks in, a large bag in tow.  As he unloads packages from the wrappings of a garbage bag, something catches my eye.  It is a piece of popular culture I immediately recognize: an Oculus Rift Dev Kit 2.  Hot off of being bought out by Facebook, I have some reservations about Oculus’ application with my project ideas, but possibilities keep popping in my head.  I’m thinking “What kind of simulations could work well in VR?  How about remaking a classic game like the original Star Fox in first-person VR?  How reasonable is the overhead with running an application in VR?” and so on.

After discussing all of the new toys and giving us the usual “this is how the real world works” lecture, the professor gives us our assignment for the week: put up an ad on the Blackboard page for the class about what we want to make.

If my memory serves me, I was the first to slap an idea on the discussion board.  Before the professor could even finish his sentence, I was scratching a prompt on the message boards: “Let’s make a game using the Oculus Rift.”

It did not take long to catch on either, as I made contact with my first potential group partner within a few hours: Kurt.  An enthusiastic IT major with experience in AI and modeling, Kurt is a perfect fit for this project.  Better yet, after informing him of my interest, Kurt tells me that he has already recruited the interest of several other candidates: Isaac, who has modeled and animated with Maya, Julia, who has an artistic background with experience in C++, and Sam, a C++ aficionado.  Within 48 hours, we already have 5 enthusiastic CS/IT majors with a unified goal of making a VR-capable video game.

This was it.  The ball was officially rolling.  I, along with my new partners, was about to be a sprouting game designer.

October 2014.

Within a few weeks, our group was up to 6 bright-eyed programmers: myself, Kurt, Isaac, Julia, Sam, and Fernando, who had experience with the Oculus Rift.  We had a name, Project Angelis, a story for our game, and a general idea of what we wanted to do.

A space shooter set some time in the next century, your mission is to capture and hold an abandoned space station array above a planet that is prime for colonization. By surviving against waves of enemy-faction mercenaries, you and your crew can establish their place as the prime stockholders of this “Next Earth.” (via our gitHub wiki page)

This was our game idea, and it sounded pretty awesome.  We were building a first-person shooter that had one game mode vis a vis Nazi Zombies or Horde Mode (Gears of War), and also had one map, but had a ton of room for added content in the future.  Moreover, we were building a VR experience, because we did not think there was enough out there for VR: it was a hot field ripe for exploration.

Here is a log of many of the design ideas we were shoving on paper as fast as our hands could type:

  • one mode, one level, increasingly difficult waves (difficulty modifier), more points (money) for player character every level, enemies not harder per AI guidelines but have more health and stronger weapons
  • sci-fi setting implies space background, weapons with “energy,” space station area
  • VR is going to require some heavy work with HUD
    • the idea here is that there is no real HUD, by the sense of the word
    • for example, all “energy” for weapons on arm, rotating a STEM peripheral or pressing a button activates this display
    • could show energy for each type of weapon (regular, special, heavy, whatever), player health, so on
  • VR also requires very high FPS, like 60-70, so we have to optimize for that
  • triggers for waves, and also environmental hazards present
  • have to handle player seeing through walls using Oculus by making screen dark at certain angles (head tilt)
  • support enemy and friendly AI
  • pause and menu function integrated
  • no effects on player camera (rain, etc.)
  • ambient noise and weapon sounds

We had our hands full, meeting 2-4 times a week to discuss the logistics of our game.  It was beginning to take shape in impressive fashion, though.

Mid-October – November 2014.

Inevitably, as we proceeded, we began to garner a few road bumps.

Deciding which engine to use was initially a struggle.  CryEngine offers incredible graphics, the potential of great performance, a wide kit of physics tools (oh, those water effects are hard to resist), and cross-platform abilities.  Unity (which was the only free one at the time) is wonderfully accessible, has a low learning curve, and boasts a huge asset library.  Unreal Engine also has a moderate asset library, and it has the potential to show the same graphical fidelity of CryEngine.  But where Unreal truly shines is in its helpful ‘VR Mode.’  Ultimately, the high learning curve with CryEngine and Unity’s poor editing capabilities gave a slight push, and we decided to go with Unreal.

Kurt, our self-appointed AI Lead, was working on research for AI methods for our game, and was uncovering the truth about AI – its nearly-insurmountable complexity.  Not only was it going to be difficult to script the AI in the first place, but he was going to have to do all of that on a platform he had never developed for.  Thankfully, several books proved incredibly helpful, and Kurt was able to get the research he needed done in time to start development (if you are curious about AI, check out Kurt’s favorite author, Matt Buckland: AI Techniques for Game Programming or Programming AI by Example).

Another problem we ran into was the sheer amount of content we were wanting to put in our game.  We assumed things would be easy or implied in game design (animations would just be there, guns would automatically fire, and so on).  Thankfully, early on in development our professor, who was experienced in game design himself, warned us that we needed to keep it simple.  “Don’t sell me too hard on this thing,” he reminded us.  And truly, this was some of the most poignant advice he could offer to the beginning game designer, as the most prolific mistake made in the gaming world, possibly the professional world as a whole, is making promises you do not deliver on.  We still wanted something special, but realized quickly that we were going to have to cut back.

Despite these problems, the design phase was running along smoothly, and our game was about to be radder than a radroach from the Capital Wasteland.

December 2014 or End of First Term.

Fourteen weeks and 75 pages of design documents later, we handed in our final paper.  Angelis was officially in development.

Here is a comprehensive list of our functional requirements up to this point: Oculus, STEM, and Omni integration; User menu enabled; At least one game mode & one level with enemy and friendly AI; Ambient noise and dynamic sound included; Environmental interaction such as weapon and friendly AI shop and score; And, of course, it was to be a first-person shooter wave-survival game.  Our non-functional requirements included: High framerate must be maintained to ensure low Oculus disorientation; All elements of the game mode included (how many waves, points, etc.); Game must have a functional economy (point systems included); Many weapons must be usable and animated correctly; Minimize disorientation in any way; And, level must be designed with playability in mind.  Of course, many other factors were taken in for our design, but this is a hint at what we had spent a semester discussing and writing about.

As the semester finished, we had solid designs for weapons, our environment, our game mode, story, sound, and the level flow.  Overall, it was a huge success, but the hardest part was yet to come.