Yep, more little fiddly coding bits today. I’m very sorry.
Today it’s a bit more about optimization and keeping code clean and quick-running from the perspective of someone that is admittedly not extremely good at it, but is trying very hard to be. This is the sort of thing that happens when you start out doing SOME programming, leaving the field for design, and then ending up needing to write code for your own projects.
Moving on! Today is some reflections and discoveries regarding the Phone 7 Emulator versus native Windows builds, and profiling. As a bonus, an early shot of my phone project, currently called Nucleus.
Posted in Nucleus, WP7, XNA
Shamelessly ganked from Wikipedia's cross product article.
Another little snippet of wisdom from adventures in WP7 and XNA. Today it’s a useful little bit of trig for dealing with a particular input case… which is likely to be fairly common on a phone touchscreen, among other places.
Picture is very much related, but be not faint of heart—vectors are actually not that scary, and dot and cross products aren’t bad at all, promise. Especially not since we’re only talking about a very little bit of them for a very specific use. This lets us cut some corners for practical purposes.
Posted in Nucleus, WP7, XNA
ah'm in ur heap, killin' ur performance
Ah, garbage collection. One of the high (and also low, low, low) points in favor of/against managed solutions like C#/XNA. High, because it frees you from having to lose sleep at night over your pointers and allocation and memory leaks you don’t know you have but are most certainly there somewhere, if only you could find them. Low, because you can optimize the hell out of your code and still take nasty performance hits from garbage collection you only indirectly control.
As with most things, I’m finding the more you understand about the labyrinthine and arcane workings under the surface of the tools, the less trouble you have with it doing unexpected things. Funny how that works out, isn’t it? What follows here is some of the things I’ve learned about avoiding major collection hits from my own sloppy code.
Posted in Nucleus, WP7, XNA
So, what have we here? A new pair of category tags, it appears.
In something of a mild departure from my usual design-oriented ramblings, I’ve decided to start discussing odds and ends I come across while working on my current game projects, which for the most part are using XNA. The one I’m spending a serious chunk of my summer working with is actually an XNA game for the upcoming Windows Phone 7 devices, so I may as well talk about that, too.
These two new categories are going to be a bit different than my writing so far. Despite not really being a heavy programmer anymore in favor of a design focus, these sections are likely to get pretty heavy into programming speak. If for some reason this is scary, feel free to stick to my other categories instead.
This is ultimately all about chronicling my misadventures, discoveries, and victories while I blunder my way to a (hopefully) decent game or three. Part of this is to document what i find for myself against future need, and part of it is to share with others. It is, after all, through the sharing of ideas and experiences that we ultimately refine them into their most useful states.
Okay, yeah… enough introduction. Time to get on with writing the first real post along these lines, coming shortly.
Today’s post is going to be somewhat academic, and a great deal less practical than I’ve tended towards thus far. Generally, I’ve tried to keep this blog focused towards interesting things that can be directly put into practice in some way, even if the overall concept is abstract. Today I will discuss a topic/theory I’ve come up with recently that doesn’t really have any practical bearing on the act of making games, but is hopefully nonetheless interesting and maybe even broadening. Who knows.
Today’s topic treads on the concepts of what is and is not a game, a well-known literary essay, and how one can possibly effect the other. I admit up front, this is pretty academic, so you’ve been warned.
I’ve been playing a lot of Battlefield: Bad Company 2 lately. I confess a massive obsession with team-based multiplayer FPSes. Battlefield I have a love/hate relationship with, but that’s for another time and post, perhaps. Today I discuss something that has occurred to me over my last few plays, and in thinking about it, it’s a fascinating instance of level design effected by game features.
Destructible terrain poses some interesting level design challenges, as well as provides some interesting options to the player. How so? Well, read on:
The QTE Controller. Image from Cracked.com
I will be honest at the outset. I pretty much despise Quick Time Events (QTEs) in games. Unlike many who share this dislike, I don’t consider them the mark of “lazy developers”, uninspired design or cloning popular titles. I am also of two minds as to whether they are or aren’t a “real” mechanic or gameplay, though I have agreed with that in the past. I’ve come to realize that the real reason I hate QTEs is because they are very rarely used well. I might argue that the nature of a QTE leads to poor use, but that doesn’t mean it can’t be done well. So, in an effort to better understand the issues and uses (as I personally see them), let’s examine and pick the technique apart.
For those in a rush, it distills down to the following:
If you want to use Quick Time Event-like mechanics, for the love of all things holy, PLEASE—integrate them well with the experience that surrounds them. Maintain the player’s state of flow.
What? A post-mortem on an academic quarter? How strangely game-designer-y!
Indeed. But as Winter wrapped up last Thursday, I started to feel like I should talk about how it went and what I learned. So here we are, with my first academic post-mortem.
Conclusions in Brief, or TL;DR
There are two overriding lessons this quarter:
Lesson 1: Don’t be so goddamned precious about your work.
Lesson 2: You do actually know what you’re doing; it’s not always a mistake.
Simple, but I think they’re both harder than they look and extremely important. That all said, I think my biggest takeaway for this quarter is simply, and I can’t stress the profundity of the statement enough, this:
Maybe I am a real game designer after all.