I have a tendency to not really do my homework over the weekend, instead opting to play tetris, or poke around on Reddit. However, I’ve recently taken to watching entire seasons of TV shows in my bouts of procrastination, and this weekend’s foray was a little sketch comedy show: Portlandia.
Enums and Bitmasks are the best!
Especially when working on software like a game, you find often certain lines of execution need to change based on what state the program is in. For example, if you’re paused, you should skip over all the main update loop stuff, but instead you should run pause menu update stuff. It gets even messier when you start talking internal states in the software.
In C, the nicest way (at least that I’ve found so far) to accomplish this is to track what state you’re in, and branch on those states. In the pause example, you would track “this game is now in paused mode”, and at the top of your logic loop you just switch on the enum you created to give nice names to these states, and you end up with something like:
And the thing is, this is perfectly fine for C. You split those functions out to a few different files if they get too messy, and your code actually stays quite maintainable.
But now enter Object-Oriented Land, after training yourself on that sort of system, and you start saying to yourself “Okay, I’ve got these room things which have a few different options for implementation, so maybe I’ll just branch on cases and track a state for the class. Works in C, so it must be good!”
The problem is, this is not so nice and clean as in C. Now, in order to maintain your code, you can’t really split out the helper functions as you would in C to keep things clean. They’re basically private helper functions, so those functions get stuck in the same file and you bulk up your code massively, giving you a huge headache to deal with down the line.
So, how do you do this nicely with clases? With classes.
Okay, that might sound dumb, but here’s the thing: a good portion of the time you have these state-based execution paths in OOP (at least in my experience), it’s because you say something like “This room could have enemies, or it could have a shop, or it could…”. In C, you’re usually looking at “This program should branch depending on user input…”.
The subtle difference here is that if a class’s “type” isn’t going to dynamically change (like it very well might in the C case), you don’t need to track it at all, nor do you need to branch. Just create a base class and use inheritance to do your job for you - that’s what it’s for.
Plus, now you get a huge upshot. In C, if your various states have some shared code between states (I need to update the enemy attacking stuff in standard execution, as well as when the user opens their inventory, but not when paused), you have a mess on your hands trying to get this code to merge. In OOP, just create another nested level and youre golden. Granted that doesn’t always work, but if it gets too convoluted, you can probably reorganize the structure to make things work out.
An extension to this idea is tracking values in bit-fields. By doing that, you are able to pack more data into a small space, and vastly optimize large fields of repeated types of data. At some point, you just start doing it by habit in other programming, especially to keep track of these states we just talked about.
This pushes a much more menacing and probably pervasive issue in programming: premature optimization. Yes, if you only need 8 values for some integer, and 16 for another, sharing bits saves space. However, if you just start doing that by default, you make your code almost illegible (because shifts and masks to get values is a lot less intuitive to an outside party than just calling a property name), and further very difficult to modify later.
But I’ll get to these other issues in more depth in a later post.
imagine a video game where you create a hero whose destiny is to save everyone, but throughout the game you start making harder and more questionable decisions, and the game gets darker and darker. and in the end you’re just standing there, clutching the controller and finally realizing you were playing the villain all along
It was good. Highly recommended. Don’t expect to have much fun, though.
Lately there’s been something of a brouhaha in the Magic community related to counterfeiting cards. I’ve been thinking about this, since I’m quite equivocally against this behavior, yet it seems somewhat contradictory with my earlier stance on hacked Pokemon. So, I’m posting some further thoughts on the issue.
Let me clarify my previous post a bit, since it seems at least some people didn’t understand:
With the opening of the Pokemon Bank in Japan, I’ve been seeing a lot of people ranting about how frustratingly poor Nintendo’s anti-hack measures are. There are a lot of frustrations coming out, with sentiments like “You had one job, Nintendo: fix the hacks!”
Well, unpopular opinion time: there is nothing wrong with “hacking”, and you have no reason to be frustrated with it.
I was actually pretty skeptical of this one at first - A Link to the Past has been my all-time favorite in the franchise for years (and don’t even bother - Ocarina of Time doesn’t even hold a flame to LttP), so building a new game around it seemed like a potential flop, casting a negative light on a great game. That said, there was no way I wasn’t going to play it - I needed more software for the 3DS anyway.
Well, finally got a chance to pick it up.
Short version: you should play this game. I’ve only played through two dungeons so far, but let’s put it this way: I’ve had the game for about four hours now, and I’ve already played through two dungeons. This game is killer fast-paced, even beyond that in A Link to the Past, and it’s awesome for it.
Let me put it another way: A Link to the Past has for years been my favorite Zelda game. It’s my number one SNES game, trumping even Super Mario World and Earthbound. Until now, nothing has even come close to being a better adventure game - and I’m very seriously considering whether a Link Between Worlds is simply a better game.
If you have 40 dollars, a 3DS, and even a remote love of adventure games: go buy this and play it seriously.
Fun bug from this afternoon: let’s say you have a custom ListAdapter you’re working with to fill in data into a ListView, and you’re trying to implement a method which allows you to insert a new element into that list. You’re competent with the use of Adapters, so you’re confident it works - in fact, the model for your add function matches most of the recommendations on StackOverflow:
So, you’re confident everything is looking good, yet whenever you actually go to add the new string, the list doesn’t update! It comes up when you leave and return to the activity (because you’re properly serializing elsewhere in code), but it won’t update on the spot.
So you go hunting further into StackOverflow to see if there was something subtle you missed about how to hook up a ListAdapter properly in your ListFragment. Maybe using setListAdapter doesn’t properly set up your fragment’s ListView as an observer for the adapter? That wouldn’t make much sense, but you aren’t sure. Perhaps it was something else…
Regardless, you spend a few hours hunting, and nothing comes up. All the errors with NotifyDataSetChanged are pretty dumb errors regarding simply misusing the class, which you’ve confirmed many times over by now that you haven’t done.
So what’s the problem?
Well, in case you had the same issues I did this afternoon, it may be that you accidentally let Eclipse fill in your functions for you, so among them you overwrote registerDataSetObserver and unregisterDataSetObserver, and they’re filled in with TODO messages rather than calling the superclass’s versions. WHOOPS.
The fix: delete those functions, dummy - you’re not doing anything in there anyway!
I caught Yveltal in a Quick Ball on the first turn while he was at full health?
And it looks like everyone else has a pretty easy time catching him, too.
…that’s ridiculous. This game is way too easy. Catching the Legendary’s supposed to be one of the game’s major challenges, but he’s practically a hand-out!
This is nothing terribly new, however. As I recall, catching Lugia in Silver was not that much harder.
What they’ve done is separated “legends tied to the main quest” and “post-quest legends”. Catching Kyogre / Groudon in R/S was easy. Catching Rayquaza was a bitch (much harder than capturing Mewtwo in the original games, IMO). The same holds in X/Y: Yveltal and Xerneas are critical to the plot, so they make it easy to capture so kids don’t feel bad that they forgot (or didn’t realize they needed) to bring a shit ton of ultra balls to the battle. However, capturing Zygarde as very difficult.
At the end of the day, though, I wouldn’t complain about difficulty on capturing pokemon when discussing difficulty of gameplay. Honestly, spending hours of chucking ultra balls waiting for the one lucky chance for the RNG to let me capture it is just a matter of grinding - not a matter of skill. I’m more concerned about the excessively distributed EXP (seriously, the new Exp. Share is OP as fuck) and bonus starters.