Several things have moved from my TODO list to my DONE list where Nucleus is concerned, and I’ve learned a few useful things along the way. In keeping with the current trend in this blog, I’m going to share the experiences once again, particularly the issues conquered.
We start with some interesting problems that crop up in trying to deal with tombstoning in XNA in particular, and then move on through a couple of design changes and other bits of progress. Tally ho.
Posted in Nucleus, WP7, XNA
This came up in both my Twitter-watching recently, and in my blog perusal habits. In particular, it’s Nels Anderson’s post on the topic that got me thinking about it particularly. The quick run-down on the issue is the question posed in the title of the blog post: Why are so many indie “darlings” 2D platformers?
The article suggests a lot of reasons, and I tend to agree with a lot of them. I’ll add one more to the list.
The state of the AAA game industry being what it is, there’s a lot of varied dissatisfaction with it roaming around. One of the high points of that dissatisfaction that I hear most often is an unfavorable comparison with something of a golden age of gaming, when tech wasn’t riding nearly as high and “realistic graphics” was a laughable concept, more or less. In short, “they don’t make them like they used to” is almost an indie battle cry being sung from hilltops in some corners, and it’s not something I can particularly disagree with. It’s worth noting that this isn’t necessarily the opinion of the developers alone or even primarily. The position the players tend to take is almost more important, and a lot of those players are looking for a “retro” experience that reminds them of the “classic gold” games they grew up with or have heard so much about.
If you look at the games put out during those periods—we’re talking the 8 and 16-bit generation—there are some common threads that emerge. Bright colors, lush character designs, fantastical environments… and in a lot of ways, the poster children for the era are predominately platform titles. The Marios and Sonics and Mega Men and Castlevanias.
In short, my personal theory on why so many of our most notable indie games seem to be platformers lately is simple. There’s a desire to recapture an era of the industry that many—among developers AND players—feel was a better time. That period had a very large number of really good platformers (though of course there were other games!). It’s only natural that we’re going to see a lot of the indie success stories come from the platforming genre. It’s the intersection of developers developing and players playing. We’ll almost certainly see more variation come along. It’s already starting to happen in bits and pieces.
I want to say this is the same way that things went back when I was a kid. But I couldn’t tell you, because I didn’t start caring about games as an industry until we were well past that particular bit of history. Makes me wish I’d known more at the time, but we all do that.
So, this is more of a point of personal progress, but worth mentioning anyway, largely because it offers me a chance to publicize someone else’s bright idea while patting myself on the back and feeling generally good about this whole blogging undertaking.
Fun By Design and my more-or-less-coherent ramblings here have appeared on GameDevBlogs, a directory of developer blog sites highlighting those unsung heroes of the industry—that is, the developers that have blogs worth reading about that you’ve never heard of because they’re not people like Miyamoto, Molyneaux, Meier, Romero, et al. In short, it’s a list of blogs written by folks down in the trenches who have interesting things to say but most people have never really heard of.
On the whole, it’s a great idea and I’ve already found some useful things by randomly chasing links there in my free time. I’m also personally pleased to be on the list (under Designers), because while I know the guy running the site has read this blog before, it still feels like something of a landmark in my nascent career to be validated in such a fashion, especially since I didn’t submit myself.
Sometimes it’s just little things that keep you working. Speaking of, I have a project update to write, I believe.
Short one today, because there isn’t much to say, but it’s just enough to be worth writing about. I took another pass at the title screen last night—mostly just changing out the buttons for new ones and a couple of minor typographical tweaks.
The big deal here is I’m now using standard Phone 7 icons for all the buttons, to be consistent with the rest of the platform (which is one of my UI goals anyhow). This was helped along greatly by Microsoft’s release of Design Templates for Windows Phone 7 which contains nice, clean layered Photoshop files with all of the assorted UI elements and helpful notes and guidelines. Including all the standard UI icons for play, pause, settings, help, sync, and so on on their own transparent layer.
So it was both trivial and a basically good idea to replace my placeholders with a set of the standard icons. This probably isn’t the last change I’ll make, but it has made the project feel more consistent with the remainder of the phone.
Posted in Nucleus, WP7, XNA
Today I took a break from working on gameplay code to get a little distance from the details and break up the sort of tasks I’m doing at any given point in time—this also keeps me from having a lot of dull “un-fun” code to write at the very end after all the main stuff is finished, something I learned from this blog entry. It went through some interesting iterations through the process of this first rough draft, so it’s worth talking about some of the concerns that came up.
This is going to be a bit of a short one, relatively, and I won’t get very code-heavy. It’s much more a post about user experience and the like. In a lot of ways, it’s very much a continuation of my last post about designing around the constraints and use of the phone. It also won’t be the last.
Posted in Nucleus, WP7, XNA
So, I feel I’ve been talking a lot about code lately, especially for someone that claims to be a game designer. This isn’t a bad thing—after all, I have to write the code myself, and designers really should, in my opinion, have enough grounding in not just code, but all aspects of game development to be able to knock out at prototypes, or at the very least communicate with specialists.
Game design, unfortunately, tends to be an area of development that is not treated very seriously. Often companies feel that game designers are unnecessary, perhaps figuring that since programmers used to handle these tasks themselves back in the day, that it belongs in their hands, or that game design means level design, or similar.
Despite my obvious state of opinionated disagreement, I’m going to leave that topic off for now. The point was just to say that I’m taking a break from talking about code for good reasons to instead discuss the design challenges thus far on bringing Nucleus to a phone device. Hopefully this will prove useful to others in their own projects.
So, I left out one detail of use in the last post that have gotten me a couple of instances of the same rather pointed question:
How exactly do you get the profiler to work with XNA GS 4.0?
True, it doesn’t work out of the box, or to be more accurate, CLR v4 doesn’t like CLR Profiler v2. For more information on this, refer to David Broman’s article on the topic. It’s a bit confusing if you, like me, are not really versed in the world of profiling. But it’s not so bad if you do a little quick internet research. Or you could just read on to see what I found out myself:
CLR v4 is backwards-compatible with V2(more or less), but it isn’t turned on by default. There are two things you need to do to get the CLR profiler working with XNA/.NET 4.0. First, since you are almost certainly on Vista or Windows 7, set CLR profiler to run as administrator, or it won’t attach properly. Secondly, an environment variable needs setting. On Win7, the easiest way to do this is open the Start Menu, right-click on “Computer” and select “Properties…”. From there, open the advanced settings in the sidebar, click on “Environment Variables…” and add a new variable named “COMPLUS_ProfAPI_ProfilerCompatibilitySetting” with a value of “EnableV2Profiler”. This will tell CLR V4 to play nice with the V2 profiler.