Category Archives: Programming

AngelXNA Experimental Games Games / Design Indie Games Industry Open Source Programming XNA

Jamming Post Mortem 2010 Edition

February 1, 2010 – 5:57 pm

Last weekend, I took part in the Global Game Jam, like I did last year and let me say it was just as fun, if not MORE fun this year than last. Our game, Quest for Stick, was really, really awesome this year, and you can learn more about it from the GGJ page and from our Twitter account. We even have a video of a complete play through of the game. The game is super pretty, only a little bit buggy, and generally I think accomplished everything we wanted.

But this year I went in knowing what to expect. How'd I do this year? What did I learn?

What Went Right

  1. The Team. Last year, I said one of the things that went right was having a team. This year, that was even more so. We had a total of 7 people working full time on the game, which, initially, I thought was way too many. So much so that I actually asked people to leave the team and considered leaving the team myself to reduce the number of people. But, when it came down to it, I decided I wanted to work on the game idea and went with the other 6 people to create the game. Honestly, 7 people may still have been too many, as communication and tasking did get hard near the end of the project, but there's no way the game would have been anything near what it was if we didn't have at least that many people. Everyone was basically tasked the whole time, and the game came out great because of it.
  2. Getting Down To Business: We spent very little time talking design this time, which worked out to our advantage. Although we spent a lot of time later arguing about how exactly the game was going to play, it didn't take away from everyone working, which was good. We got down to making something playable quickly, and didn't try to design too much stuff up front.
  3. Tools choice: Last year, I was super happy with XNA. This year, the team used AngelXNA, even though I was the only one familiar at all with it, and I was the really the only one well versed in XNA. Even though I spent a lot of time helping people understand Angel / XNA, it was still, by far, better than attempting to use only XNA. It performed a lot of the heavy lifting for us in terms of doing animations, placing and managing actors, and, surprisingly, editing levels, though this is its own bullet point.

What Went Wrong

  1. Unclear tasking: Occasionally, we got duplicated work or weird moments of down time because, like most game jams, people just shouted out things they needed. Kate was really the only person keeping track of most of these tasks, and really only for herself. For the artists, no one was really in charge of knowing what art was still needed and who was doing what. For a team this large, what we needed to create and consult a list on a whiteboard or cork board that had any asset requests, who was potentially doing them, what was in progress and what was up for grabs. This would have avoided duplicated work and would have given us an idea of how much work was left.
  2. Late Playable: Despite my work to prevent this (more on this later), we still didn't end up with an actual playable game until mid day on the last day. Just having *SOMETHING* sometime on Saturday to hand to the artists and designers to make levels on would have helped. We did have lots of pieces that worked, essentially, but didn't get them integrated together fast enough.
  3. Encapsulation problems: We had three programmers working together on individual parts of the game, which helped not only keep them tasked without stomping on each other, but made it so people were in charge of very small systems. However, some of the systems were weirdly encapsulated, and required copying and pasting over when we actually got to the point of integrating. Though this actually ended up *helping* at the very end, I would have liked fewer instances where I had to copy and paste the code from one class to another in order to integrate a new system into the main game.

What Didn't Work

So, these things really didn't go wrong, but they were things I was hoping would help us during the jam, but didn't.

  1. The Simple CI: Before the Jam, I wrote a simple python script that would query a mercurial repository, pull down new code, build it, copy it up to a network location, then message everyone over gchat. This was awesome in theory, but not so much in practice for a few reasons. First, it didn't work so well. If anyone was signed out of gchat when it went to message them, the CI would get stuck in an endless loop. Second, the network drive would occasionally flake out and not be able to take the new build. Third, we didn't have anything the team could play until Sunday, so the CI ended up being useless until then.
  2. The Angel Editor: The editor in Angel was an awesome idea, but when we got to the Jam, it was buggy and untested. It didn't save out things correctly, crashed, spawned items in weird places, and didn't work at all with our custom actors. In addition, the editor saved all levels out to the build directory, which was great for everyone but the people who were using it. Besides fixing the other editor bugs, in the future, the editor will probably need to detect whether a debugger is attached, and figure out where to put the levels from there, or create a custom levels folder that can be easily moved back and forth and through to an integratable build.

All and all, an awesome Jam. Please play Quest for Stick, and let me know what you think. I'm super proud of it.

Tags | Permalink | Comments (2)
Games / Design Industry Programming

Obligatory New Years Post

December 27, 2009 – 5:44 pm

I didn't do this last year. I don't know why. I probably wasn't in a reflective mood last year. This year, I've been in a very reflective mood, as you can probably tell from many of my blog posts over the year. I reflected on a lot of things: open standards and web identity, DLC, the possibility of being an indie game developer, and the state of computer science education. Until August, I was even able to post about twice a month, which is pretty good for me.

Besides blogging, what did I do in 2009?

  • Me and several other Tools SIG members launched of the Toolsmiths blog, which is going very well, though we have dropped off a bit. Hopefully we'll be able to pick up again in the New Year.
  • I participated in the Global Game Jam, which was a blast, and I'm sure will be a blast again this year. I've made plans already to make this a rockin Jam, and get everyone as coordinated as possible right out of the starting gate. We'll see how that goes.
  • Darren and I also created AngelXNA, which I've been using and enjoying, and hopefully improving for this year's Global Game Jam. (More on that in another blog post).
  • I learned to love distributed version control, a trend that I'm sure will continue.

So what didn't I do in 2009 that I really wanted to get done? The main one is that I didn't finish a game. I've got three currently on my plate, two of which are mostly coded one of which is still in prototype, but nothing finished. This is really frustrating for me for a few reasons. First, the longer I wait to release, the harder it will be to stand out, especially on services like XBLIG. Second, like most people, I entered the game industry to create games, but I've yet to see an actual design of my own make it to a finished, polished state, only ever to a useable prototype. I know this is true for many people, but considering my background I should be able to finish a game. I am going to try very hard to correct this this year.

What do I think is coming in the New Year and new decade? Hopefully you'll see my first game. For more serious predictions, I think you could do worse than listening to Joe Ludwig.

I think that we'll also see more trends towards user created content and personalization, to the point where I think you will actually, eventually, see a game come out on a console that will allow user created mods. The groundwork for this is already being laid out by the Rock Band Network, although it's still a long way from there to a console mod community.

Here's to a new year, new adventures, and hopefully some new games!

Permalink | Comment (0)
Builds

GameX Builds Talk

December 14, 2009 – 2:31 pm

A few months ago, I gave a talk at GameX about improving builds and build process, and I've finally gotten around to posting the slides on my website. They are now available here.

There are a few things I wish I'd hit in the talk that just didn't make it in, mainly with asset optimization and best practices for version control, but much of that is in flux for me right now, especially with my new found fascination with Mercurial (and it's very real lack of binary / large file support). Eventually, I'd like to try working on systems for Mercurial and distributed version control which would allow feature branches of artwork, but I'm not sure where to even start.

But all of that is a subject for another day. For now, enjoy the talk!

Permalink | Comment (0)
Activism Games / Design Industry Programming

Marketable Skills: State of Game Programming Education

November 6, 2009 – 12:42 pm

My good friend and educator Bill Crosbie is asking some tough questions on Twitter, specifically about what to teach fledgling game programmers to make them the most marketable to game companies when they graduate. Now, you might not be able to tell from the Twitter conversations, but Bill is actually very concerned about giving his students a good, foundations based, computer science education, while also giving them the opportunity to make games, and giving them skills that they can immediately transfer into the workplace, all in less than the two years he happens to have them. And what he's asking are actually really hard questions, and got me thinking: What would I want out of programmers coming out of two year and four year programs, both those that are focused on game development, and those that aren't? What can I tell Bill to do to make sure that I would at least consider hiring his better students?

The Never Ending Conflict

This comes down to a never ending conflict that educators are well aware of: the conflict between giving a student marketable skills, teaching them the tools and technologies that are relevant "right now" that they can put on a resume and will immediately generate hits on job search websites, and giving them an actual solid education in computer science and software engineering. Ask most programmers in the game industry (at least the ones I know) and they will tell you the later is more important, but look at who actually gets hired and the former plays a very obvious role. The problem is that when I'm hiring a programmer, I want someone who's smart and gets things done, but I also don't want to take the time to teach them all of the skills that they're going to use on a daily basis. It's a tough balance, and getting programmers that don't understand things about your core technologies, or at least their underlying principles, can be dangerous.

In addition, technologies go out of date so fast that teaching one specifically can be counterproductive. C++ has been the de facto standard in the game industry almost since inception, as we've needed the control and power that C++ provides, but the technology that we're working with under the hood can dictate exactly how we can use C++. Students taught to think about single threads of execution on x86 processors, using primitives that would be perfectly fine in other industries (like stl vectors and strings) would be screwed in today's game industry, an industry which is (now) all about squeezing as much performance as possible out of multiprocessor, multicore systems on x86, x64, PPC and Cell chipsets. And interestingly, this is exactly what's happened. Students taught to think ONLY in an object oriented paradigm have trouble parallelizing their code and thinking in terms of small executable chunks that don't suffer from things like race conditions and cache misses, if they even know what those are.

But what's academia to do? Most game developers won't even look at a programmer unless they have C++ experience, understand OO concepts, have done at least some work in DirectX, OpenGL, or Win32 programming, and has as a significant portfolio of work. This leaves professors looking to help game industry hopefuls little time to discuss things that are essential to computer scientists, like the benefits and pitfalls of functional languages, strong and weak typing, lazy evaluation, early and late binding, combinatorics, state machines and automata theory, synchronization patterns (semaphores versus critical sections), common concurrency issues and how to avoid them, and even compiler and virtual machine theory. Even if they get through all that theory, how many schools will be able to talk about the inner workings of modern chipsets, cache coherency, synchronization primitives, compiler intrinsics, and virtual memory? If you're a recent college graduate that can actually give me a definition on all of those terms, explain how they're relevant to modern computer software and game programming, and has a fundamental understanding of any modern game API, you're way better than I was when I graduated, and maybe better than I am now because I'm not sure even I could do it. And I can't tell you how much of it is important to know when you graduate, and how much you can learn either on the job, or on your own. Even the IGDA curriculum framework lists so much stuff that it would be almost impossible to push through in a 2 or even 4 year program. You have to pick and choose.

So if I can't figure it out, what's an educator supposed to do? Take a best guess I suppose. Fundamentally, though, I think they need to teach what colleges and universities have said they're teaching for years.

Teaching How To Think, How To Learn, and How To Work With The Tools

Most liberal arts colleges and universities still say they teach their students how to think. They're not necessarily teaching skills, and I like that. That's what I want from my programmers: I want them to know how to think, and, more importantly, how to learn. But there's nothing that says that this must all be done with theory, or that it should be done purely with theory. In my mind, the problem is that Computer Science and Computer Game Programming programs come out of science and math programs, and follow their pattern for how to structure classes: either 3 credit classes with focused homework assignments with little to no cross class application, or 4 credit labs where a single lab is considered enough to create a program that demonstrates theory. This is not only not enough time, but it doesn't encourage long examinations of hard topics, it doesn't encourage learning by failure, and it doesn't encourage learning why it all works the way it does.

How many schools actually look to the art world for inspiration? In most art schools, you have 3 credit studio classes, which last actually 6 to 10 hours per week, have only 2 to 3 projects per semester, and are combined with classes on fundamentals that can help improve project work. I don't think I ever had a class structured this way during my computer science education. The closest I ever got was a Software Engineering class, which wasn't really about software engineering as much as software planning, which is completely different. But, for programmers, these project classes should not necessarily be introducing new technology. At least at the start, students should work from the base competencies of whatever the school was teaching the previous semester, and early project classes should expect failure (though not say this out right), and encourage students to spend several days at the end of projects to examine their work for flaws in their design and flaws in their process, not flaws in the final product. This is where we teach students how to learn, and how to find the problems in their own work: by screwing it up royally.

In addition, I feel that early theory classes should be kept separate from those that are teaching applications of programming, especially those that are focused on programming in specific languages. However, the two classes should be linked together and move in conjunction. Each class on algorithms and data structures should be paired with the class that teaches its specific application to the language they're working in, thereby teaching both programming and theory. This I think is the major failing of most CS programs. They teach programming, usually in a specific language, and expect the students to pick up theory on the way. In the worse cases, the students return later to have classes specifically on theory, which is sometimes a repeat of what they already learned, just presented as theory instead of a feature of the specific language. By making that clear separation of learning theory and learning practice in two separate but joined classes, your students should progress faster in both. It also creates a flow in teaching and a reason to move to languages as you progress. When theory classes are ready to introduce things like how memory works, caches, cache coherency, pointers, and the like, that's when you can move your classes on programming into teaching C++. As you learn concepts in functional languages, you can start teaching ML in programming classes. As they learn the theory, they can see how it was applied in the language they're learning.

Finally, by the end of any given program, students should be spending a majority of time in studio classes, working on projects that utilize everything they've learned with frequent review of architecture and progress from their professor. However, this should be supplemented with theory classes that go beyond what they'll need to use on simple projects, like topics in programming languages, lexer / parsers, and the ability to prove algorithms correct, and include seminars in currently relevant technology and concepts (guest speaker series are great for this).

Doesn't Answer The Question

Interestingly, I'm not sure if this actually answer's Bill's questions, but it gets a lot of thoughts off of my head. I actually had an entire set of semester plans that went with this post, but scrapped it when I realized I have absolutely no experience in that regard. I can tell you what I want, which is basically separate theory and practice classes joined at the hip in early stages, followed by advanced topics in CS and software engineering paired with Studio classes. But, for me to tell you exactly how those classes should be structured doesn't make any sense.

So hopefully, without answering the question, I've been at least a little helpful.

Permalink | Comments (6)
.NET AngelXNA Programming Tools XNA

Angel, New Features, Documentation?

September 18, 2009 – 5:40 pm

I just pushed a new feature to AngelXNA which integrates a very simple (and currently fairly dirty and incorrect) lexer / parser into the console. The nice thing about this lexer / parser is that it allows the Angel console to now track C# objects, instead of just strings. In addition, you can bind various properties and methods of those C# objects to be console callable, which has made actor and level definition pretty easy to do in the new versions.

Here's an example of the old Angel adf files:

ActorFactoryInitializeActorClass PhysicsActor
 
ActorFactorySetColor 0.5 0.5 0.8 1.0
ActorFactorySetSize 3 3
ActorFactorySetDensity 0
ActorFactoryAddTag maze_wall

Each of these was marked with the [ConsoleMethod] attribute bound to their singleton via reflection. It was cool, and it worked, but here's the new system:

ActorFactory.InitializeActor(PhysicsActor.Create())
 
Color = Color(0.5, 0.5, 0.8, 1.0)
Size = Vector2(3, 3)
Density = 0
Tag("maze_wall")

In the back end, ActorFactor.InitializeActor and PhysicsActor.Create are static methods on C# classes, marked with [ConsoleMethod], and the Console class automatically finds them. Initialize actor has an implicit "Using" which means that the object passed to it is the subject of any calls until an EndUsing (or EndActor). So, in reality, the new adfs are shortcuts for console scripts that would look like this:

ewActor = PhysicsActor.Create()
 
newActor.Color = Color(0.5, 0.5, 0.8, 1.0)
newActor.Size = Vector2(3, 3)
newActor.Density = 0
newActor.Tag("maze_wall")
 
World.Add(newActor)

Each of the calls to set actor properties (Color, Size, Density, etc.) are all just properties on the C# Actor object, marked with [ConsoleProperty].

What all of this means is that if you want a class that's accessible from the console and has properties and methods you can call here's what you do. First, create a class that has methods and properties that you want console accessible tagged appropriately, like so:

public class MyConsoleClass
{
     public MyConsoleClass()
     {
 
     }
 
    [ConsoleProperty]
    public string Name
    {
        get; set;
    }
 
    [ConsoleProperty]
    public string Value
    {
        get; set;
    }
 
    [ConsoleMethod]
    public string GetMyInfo()
    {
        return String.Format("{0}:{1}", Name, Value);
    }
 
    [ConsoleMethod]
    public static MyConsoleClass Create()
    {
        return new MyConsoleClass();
    }
}

Second, compile and run you AngelXNA application. It will automatically detect your new class and allow you to now issue the following commands in the console:

myVar = MyConsoleClass.Create()
myVar.Name = "My Name"
myVar.Value = "My Value"
Echo(myVar.GetMyInfo())

So, that's pretty cool! The whole system needs work, as it's fairly dirty. The execution / parse tree can't handle chaining right now, so commands like myVar.Actor.PerformAction() won't work. In addition, there's a lot of boxing / unboxing of values going on, and some wonkyness where the console works mostly in floats. I'm not sure how much of this I'll have a chance to correct, but hopefully much of it as we move forward.

In addition, this whole system needs documentation on our wiki. If you want to help out please let me know.

Lastly, Ian Bogost and Borut Pfeifer have pointed out (via twitter) that AngelXNA definitely needs to be more user friendly to start with. As Ian said, we need things that " will help people get started' and "help them get up and running" quickly. Borut pointed out we may need more screens for the Intro game to explore a lot of the features, but I'm thinking we need more than that. For people that have tried Angel / AngelXNA, what keeps you from starting work quickly? What's confusing? How can we improve the experience and get you working on prototypes quickly and efficiently?

Permalink | Comment (1)
Industry XNA

Community Games Pricing

July 24, 2009 – 9:56 am

Microsoft today announced that they're changing the pricing model for community games. I both like and dislike this, and in some ways it does actually hurt me in the long term, but I'll get to that. The only thing I like about the new changes is that they've pushed the minimum price point down to $1. I know there are games and applications out there that wanted to charge less, so pushing things down seemed smart.

But there are many things I don't like about the changes.

First, I'm unhappy that they moved the $2.50 price point to $3.00. No one actually keeps track of the conversions, and 200 points was a nice round number that people understood. It meshed with XBLA's round number schemes. 240 points, even though it actually translates to slightly more money, won't have people buying because it's a psychologically weird number. 40 points translates to 50 cents, but psychologically it translates into something completely different. Seeing this weird number, potential buyers might actually do the conversion and think about the price. As a person developing a game that will rely on the impulse buy, I'm not happy about that. In addition, people buying community games will now be left with a weird 60 point remainder, which they won't really be able to do anything with, unless we see XBLA games selling for 460 points ($5.50) or single downloads for 60 points. It's just odd, and it will turn more people away than it will attract.

Second, I'm unhappy that they moved the 50 meg cap to $1, instead of keeping it at $2.50. I'd rather have a 25 meg cap on $1, and a 50 meg cap at $2.50, or a 50 meg cap on both. I've actually been working hard to keep our sizes down to below 50 meg because I wanted to hit the $2.50 price point. Now that it doesn't matter, maybe I won't bother, but it'll just make me more lazy about things like asset optimization, not improve the quality of the game in any way.

Third, why did they feel the need to get rid of the $10 price point? I know very few games are good enough currently to warrant the price, but that doesn't mean it will never happen! Why are 3 price points the magic number here? Why can't it be 4? Why why why?!

Anyway, this all hurts me because my Community Game is getting close to finished, and I'd planned to release it at the $2.50 price point to grab some people doing impulse buys. I feel the game is worth more than $1, but I'm not sure others will feel that way, which is where the predicament comes in. With $2.50 being the lowest price point, anyone playing the game could easily just dismiss the set price as the lowest available. Now they'll actually think about whether or not it should have been priced at $1 over $3, coupled with the fact that it will leave them with that 60 point remainder. All in all, I think if the game I'm working on had been released before this pricing structure change, it would have done better than after the change, and that's just a damn shame.

Permalink | Comment (0)
Breaking In Industry Programming

Newbie Tips: What Language Should I Learn?

June 9, 2009 – 9:31 am

One of the most frequent questions I get from high school and college students, especially after they read my school article in GCG, is "What programming language should I learn?" Generally, I reply to this question privately over email, but I figure it's something that I should have written about a long time ago, so here it goes. The answer is… it depends.

Now, I'm sure everyone was thinking the answer would be C++, and for the most part, you're right. But you're thinking I get this question from ONLY programmers, and only programmers that are at the level where they'd be able to work with C++ and not get intensely frustrated. Certainly, all people looking to be programmers in the game industry MUST learn C++ and MUST learn it well. But I'm getting ahead of myself. We should first look at the different type of people that ask this question and first ask them a key question: What do you want to be in the game industry? The answer to this isn't always a game programmer. Believe it or not, some artists ask this question, and I don't blame them. The more technical skills any artist has, the better they're going to be at their job. So, I've broken this down into three groups:

Programmers

If you want to be a programmer, and I mean a "real" programmer, and you're at least fairly comfortable with a computer, I recommend you start with C++. A lot of people are going to yell at me for this, because they think C++ is prohibitively hard to learn, that it's on its way out, that it will be taken over by more interpreted languages like Python or C# and that a programmer learning C++ is wasting his or her time. I don't buy it. Almost all AAA game companies still use C++ when it comes to systems level programming, and I don't see that changing any time soon. And even if I did, I'd still recommend C++. Why? Because you are always more comfortable in the language you start in, and C++, through its many idiosyncrasies (and, honestly, poor language design) forces you to think about things like memory management, simple optimizations, side effects, const variables, const methods, references, pointers and (as you get more and more advanced) things like v-tables, performance of virtual methods, memory layouts, and memory trashing. More modern languages do all they can to protect you against some of this stuff, but even they have weird performance pitfalls that, unless you have a sound basis in "close to the metal" programming, you won't fully understand and that you won't be able to optimize away.

In addition, many, many languages, are based off of C++ in some way shape or form. Regardless of whether they carry over any syntax or keywords, far too many languages are classified as "C-like" (including many scripting languages) for you to ignore it and think you'll be able to slide by without a full understanding of it.

That said, if you're in middle school or early high school, I will say there is no problem learning other languages that make your programming life easier, like VB, Python & PyGame, DarkBasic or C#. By the time you hit college, through, regardless of whether your school teaches it or not, you should be learning C++ on your own and some of the libraries that are used in game development with it (either OpenGL and / or DirectX, with a smattering of Win32, just for fun ;) ).  Just be aware that if you're starting in a higher level language, that you may be forming some bad habits that may end up being hard to break.

Designers

Okay, so you want to be a designer. Join the club. Now, everyone wants to be a designer, and my advice for this was, not too long ago, think of something else to do. That is no longer the case. I now believe you can become a designer in the industry, just not the role some people think (aka, not the person who comes up with the idea for the game in the first place). Regardless, I won't go into detail about this in this article, suffice to say most designers should learn programming in some form. My recommendation is to learn the languages you will most likely use on a daily basis, and those are the languages that are used to automate tasks in Excel. This means VBA and VB.NET (and / or C#). You will be surprised just how powerful these languages are, and how much more effective you will become at working with Office after having learned them.

If you're really adventurous, you may also want to learn a scripting language like Lua or Python, and learn a game making framework like PyGame. Why? Well, cause, then you can make your own games pretty easily, and that's what you wanted in the first place right?

Artists

For your run of the mill artist, I say learn two languages: MaxScript (for obvious reasons) and Python. Unlike MaxScript, Python is actually used in other places than art, and is a more fully featured language. However, it's also integrated into most art tools, including Maya, so you waste no time by learning it. As a bonus, Python has PyGame, which means if you have even the slightest understanding of Python you can actually make your own games without programmer assistance. And if you can do that well, I hate you, as I have no art skills what so ever.

I also recommend that artists at least take a look at C#, as many game companies are starting to integrate C# into their tools pipeline, and a smart tools engineer will find ways to allow small C# "scripts" to be run on top of their tools (this is actually very easy to do, though it takes a bit of forethought in the tool's design, but I digress). Anyway, learning the language won't hurt you, and may help as C# becomes more common.

What about…

So, many people will read this and wonder what happened to their favorite tool or language. Flash and ActionScript in particular are missing, as are the scripting languages for tools like GameMaker. Well, in my mind these are specific tools, and if you want to use these tools (or you're forced to use these tools), then obviously you will have to learn their languages. The good part is that, as you learn programming languages, it becomes easier to pick up other programming languages, and the ones that I've mentioned as places to start are all languages that will give you a firm enough basis that you should be able to pick up other languages easily. I don't see the purpose of learning a specific language first. Their applications are so limited that their practicality is diminished.

So I hope that answers the question about what language you should learn. Hopefully this helps point some people in the right direction. Good luck everyone!

Permalink | Comments (3)
.NET AngelXNA Programming XNA

AngelXNA v1.0

May 1, 2009 – 12:24 pm

Thanks to a lot of help from Darren, today we're officially announcing the release of AngelXNA 1.0. For those that don't know, AngelXNA is a port of the Angel prototyping engine made by EALA and released open source not too long ago. The justification for making a C#/XNA version is that I, personally, like working with C# more than I like working with C++, at least when I'm trying to do prototypes. C# allows me to program faster and worry less about things like memory leaks, memory trashing, and weird side effects. By utilizing XNA, we get a lot of stuff for free, including input handling, sound, and music handling, along with the possibility (though it has not been tested) or running prototypes on the 360.

The interesting thing about creating / porting Angel was a question Darius posed to me while we were working on it, which is this: were there any decisions we'd made about the design of Angel that favored simplicity of creating games over speed / efficiency? Did we do anything that we wouldn't do in an actual game engine, just because it made programming games simpler? It\'s a pretty good question. Certainly, neither Angel nor AngelXNA take advantage of memory optimizations like object recycling or pooling, and there's no inline optimizations in AngelXNA. In addition, we didn't optimize any of the rendering or animation systems by doing things like pooling similar objects together, and AngelXNA ends up opening SpriteBatch blocks a bit more often than it should. But the question is could either version of Angel be optimized this way and still keep the same interface? It's a pretty good question, and right now I'm not sure. Regardless, I think AngelXNA is pretty easy to develop on and runs fast enough to make it a pretty nifty prototyping system, so at least that part is a success.

If you'd like you can grab the v1.0 tag from our bitbucket site (zip direct link), and Darren did a great job of creating some initial documentation on the wiki, so please check it out and tell us what you think! Darren and I (and anyone else who\'d like to contribute?) will be looking at moving on to version 1.1 soon, which should include some simple pathing using A* (something that\'s in the original Angel) and some other simple AI.

Permalink | Comments (5)
.NET Games / Design Industry XNA

XNA and Community Games Sales Disappointment

March 31, 2009 – 12:17 pm

Right at the tail end of GDC, Microsoft released to developers the XNA Community Games sales figures. While many of the top sellers are keeping their data private (including Miner Dig Deep and the Masseuse products), many have released their data to Gamasutra, which has a very nice in depth discussion. The general consensus? Most developers are disappointed.

Now before I get into defending Microsoft and the XNA platform as a whole, let me say that the release of sales figures after GDC was certainly not a mistake. If sales had been going well, Microsoft would have done everything in its power to get those figures out either before or during GDC in order to bolster more developer support for the platform. As it is, they knew most developers would be disappointed with the figures, and thus waited until after GDC when the news would have the smallest impact. PR guys are smart like that. So trust me, Microsoft knew you'd be sad and is trying to cover up its mistakes on the platform.

Now I'm going to play the devil's advocate against the indies here (who I respect greatly), and just say that I think Microsoft is getting a bad wrap for poor sales figures. Most of the articles I'm seeing are about how Microsoft isn't promoting the platform, and how Microsoft isn't promoting their games, how Community Games are hard to find on the NXE (TRUE!!! I complained about this already!). No one's blaming themselves for the lack of good games on the system, which is relegating it to second class citizenship. No one is complaining about their own lack of marketing. In fact, some of the games that have pretty good sales figures (not great) are marketing themselves, and are seeing profits as a result. You can't expect Microsoft to do all of this for you, just because you're on their service that they provide you mostly for free. That said, even those with good marketing (like Weapon of Choice) aren't doing great, but at least it doesn't look like they're blaming Microsoft at all. They're just disappointed.

Of course, many are taking this opportunity to talk about how much better iPhone would be to develop for, but I can't stand these comparisons, mostly because the type of game that is going to sell well on the iPhone is going to be different from one that is going to sell well on a console. iPhone is all about the impulse buy. $1 for some small app that looks fun that I want to play right now because I'm bored on a bus, or that serves a need I have right now, but may never have in the future. If that's the game (or app) you're developing, you need to be on iPhone because your game isn't going to sell well on XBLCG anyway. Console sales just are not going to work that way, and you shouldn't expect them to. The amount of money, time, and polish that needs to go in to something that will be sold on a console is higher (IMO) than something sold on a mobile platform because it needs to capture the user's attention for longer. On iPhone you develop for a short attention span, and on XBLCG, you need to develop for the longer attention span. It's just necessary.

Lastly, I want to reiterate how Microsoft and Apple are the only people that are providing an open platform for development, and should be lauded for that alone. It seems both companies thought of the idea at the same time. The 1.0 refresh of XNA was released in April of 2007, a full year ahead of the iPhone SDK, and Microsoft announced Community games in February of 2008, a month ahead of Apple's SDK announcement (which included their app store announcement). However, Apple shipped first and with more features (including sales figures) starting in March of 2008, whereas the NXE (which included the CG store) launched in November of 2008, and didn't get sales figures until last week. In general, both companies deserve kudos for opening previously closed development platforms, and for giving the average person the opportunity to make money on the platforms, but when it comes down to it, they're still very different platforms with different concerns, and attempting to compare them (in my mind) is absolutely ludicrous, so much so that I won't even talk about the millions of features Microsoft HAS to offer in order to keep up with their own XDK technologies (including parental control) that Apple hasn't even touched on yet.

Really lastly, I have ideas on what really needs to happen for CG to really be a "quit your job" platform, but that will have to wait for another post.

Permalink | Comment (0)
Programming User Interface

The Microsoft Future… pretty cool actually…

March 3, 2009 – 2:16 pm

My friend (and Microsoft employee) Steve shared a video with me that is kind of a concept video for what Microsoft sees interfacing with computers will be like in 2019. The original post for the videos is located here and is really cool. Cool enough that I felt the need to comment on it, at least a little. In general, I think the concepts are pretty achievable, if not by Microsoft than at least by someone by 2019. The general concessions throughout the video are that the future of interaction is:

  1. Very thin, multitouch screens and surfaces, that will be prevalent in every aspect of your life.
  2. Lots of portable devices, with screens and without, that will automatically detect each other and react accordingly
  3. Lots of systems that use digital paper or some form of digital paper.

I think most of this is achievable, but there are a few things that stand in their way, even for these assumptions. For the second point, you HAVE to have a better networking protocol than Windows Networking, and a better discovery system than Bluetooth. mDNS / DNS-SD may be a start, but I don't know of any good protocols that exist to automatically detect new devices in close proximity to each other, and what services they provide. That's the first problem that has to be solved, sooner rather than later. For the third part, you first have to make digital paper affordable. That's an issue, as it's out of reach for most consumers right now. Maybe by 2019 I'll eat my words, but I don't see it being economically feasible any time soon.

In addition, there are a few things I have to say look cool, but I don't see being in the future.

Right at the start of the film (at about 10 seconds in) the system recognizes that a girl has drawn a dog, and what's there acts like a dog. I'd be surprised if that's actually achievable for everyone's version of a dog, especially for a 10 year old's drawing. The ball part is realistic, but having the system recognize "dog" and "ball" and have them interact… that seems a little pie in the sky to me, and this is coming from a game developer. Let's face it, even Spore had to seriously limit their drawing capabilities to enable their procedural animation system.

At about 3:46, we see somewhere where identity management becomes an issue. Would it be awesome for me to just carry around a device that had all my meeting notes on it, and have it automatically detect a co-worker's computer, network to it, and show communication history on a set of projects? Certainly. And it's certainly possible. But what if I store personal things on that same keychain? Or conversations with other clients? I don't want the business table showing that. I don't want it reading it, or attempting to read it. I don't want to have to specify to the table right there "This is what you have access to." In some cases, I just want it to know. Identity management is a huge issue there, and no one's solved it, let alone Microsoft.

Starting at about 4:10, we have that digital paper problem. Not only is it inexpensive digital paper (I assume) but it's touch screen, foldable, networkable digital paper. This seems a little far fetched. I look forward to hardware companies proving me wrong.

Aside from these problems, much of what's there gets me excited about the future of interactivity. I certainly think the future will look similar to this, but I think the larger issues of identity and task management are far from solved, and more important than the flashy ability to point at a piece of information and drag it to your tablet. This type of interactivity is going to require a new way of looking at how we want to share information, with whom, and when. It's going to require a new look at how we group pieces of information (Mozilla Labs is actually more interesting in this respect) and how we use applications together in tasks, projects, etc. That's solvable now (in some cases) but even Windows 7 (as cool as it is) only begins to scratch the surface. In addition, this goes beyond the Office team, and should be looked at by Microsoft as a new initiative, to break free of the start menu, task bar, quick launch, etc. and start thinking about how all of their applications work together to form a meaningful whole in this fashion.

I'd love to be a part of this, but I work on games right now… and I don't see that changing soon.

Permalink | Comment (1)

« Previous Page — Next Page »

« Previous Page — Next Page »