When implementing storage for Railgun, I screwed things up pretty badly. Not enough people talk about where they screw up, so I thought I’d braindump stuff to the blog in case it might help someone.

The first and biggest mistake I made was in treating the storage process as a synchronous action. Basically, I would get a StorageContainer and write to it, then wander off expecting the GC to handle it when it was done. Then I’d try to save data again, and when I tried to get a StorageContainer the framework would throw an exception because the previous one wasn’t disposed.

My other mistake was not thinking through the whole SignedInGamer thing. I simply didn’t know what to do when a gamer signed in or out, had never really considered it, and when I started trying to figure out how to handle it… well, I just didn’t have time.

The architecture I think would work - untested; haven’t had time to try it - is that I don’t really care if a gamer is signed in until a game is started. This is a basic contract with the game: whenever a game is in progress, the active player is signed in, and it will always be the same active player. I guarantee this is true by quitting to the main menu if he signs out, so nobody else can sign in on the same game. It would be nice if I could autosave his game and settings before quitting, but I don’t know whether I can - do I get the notification before or after he signs out? I need to research and test that.

Outside of that contract, a static StorageManager class would be used to do the heavy lifting. Essentially, I’d register a component which processed game saves, which would work like this on each update:

If there is data to process
   If no request is pending
      If the storage device is not null
         If the storage device is connected
            If the storage container is not null
               Set request pending
               Process the data: callback to "Data Processed"
            Else // storage container is null
               Set request pending
               Get the storage container: callback to "Container Loaded"
         Else // storage device is not connected
            Set request pending
            Pop the guide: callback to "Device Selected"
      Else // storage device is null
         Set request pending
         Pop the guide: callback to "Device Selected"
   Else // request is pending
      Do nothing
Else // no data to save
   Do nothing

Data Processed
   If loading data
      Store in appropriate location
   Remove data from list
   Clear request pending

Container Loaded
   Store container reference
   Clear request pending

Device Selected
   Store device reference
   Clear request pending

This process seems like a good architecture, but again, I haven’t tested it. I believe the container callback might be unnecessary, but I’m just braindumping at the moment. The list of data to process would essentially be a filename, a boolean “load” flag, and an object reference to the data. When saving, this data would be a copy of the original, so we save the data as it existed when save was requested. When loading, this would start as null, and the file would be loaded into that object.

I’ll probably get around to testing this sometime, but not right now.

So the final day of DBP submission, what should happen, but Jack Thompson gets disbarred.

This is truly a great day in the history of gaming.

While sliders and color schemes are done, I’ve only got 25 hours to finish save/load. It’s been a stone bitch, and I may just yank it altogether - after all, there’s nothing that says I have to offer save/load.

The XNA Creators’ Club forum has made one universal complaint about Railgun: you can’t lose.

This was rather the point, but it’s pretty stupid to ignore something you hear from every single person that plays your game, so gameplay has been radically changed. In the lower left corner of the screen, I’ve added an energy gauge with a counter and a ring of lights around it.

The lights around the counter track powerup status: when all of the lights are lit, the next colored brick you shoot will drop a powerup. The gauge fills as you destroy bricks, and whenever it’s filled, the counter goes up by one. Whenever you shoot a transport ship, the gauge empties and your counter goes down by one. If your counter is at zero, shooting a transport ship will end the game.

And let’s also not overlook the basic reality that XNA is freakin’ awesome. This suggestion was made by several people yesterday afternoon, and it has literally been implemented and tested overnight.

New setup is here. (Actually, all the setup links point to the same setup.) And since things are reasonably stable as they stand, here’s the first public XBox 360 version.

To do list:

• Slider dialog for effects/music volume, controller sensitivity, and time warp
• Design and add the six alternate color schemes
• Save/load… storage on the 360 scares me, so I’m procrastinating

With roughly 50 hours to finish, and eight of that taken up by interviewing at Microsoft on Monday, this is going to be a tight squeeze. However, even if I can’t finish any of this by the deadline, Railgun as it stands is something I’d not be ashamed to submit for DBP. I could cut screenshots and video now, if I wanted to puss out, but I’d really like to have these implemented before I submit.

Here’s the latest build… still a half dozen bits to do, some of the menu items don’t work (notably color configuration, volume, controller sensitivity, and save/load), mouse doesn’t have full support in dialogs (left click dismisses all current dialogs), but I should have some of this written and tested by tomorrow. Within spitting distance of submission, though.

There’s an intermittent bug where the game freezes at the start of a level, which I’ve yet to track down.

Having covered the basic descriptions of the seven critical programming skills, it’s time to sit down and actually write some code. Start by opening Visual C# and starting a new project; rather than selecting a Game Studio project, however, select a C# Project and choose “Console Application”. Name it “SandwichMaker”.

(more…)

There are a number of people out there worried that they’ll just be embarrassed if they enter the Dream-Build-Play competition, because so many great games will show up.

Let’s take a quick reality check.

Ninety percent of the people who registered won’t actually have anything to submit. If you don’t submit because you’re worried about losing, that includes you.

Half of the remaining ten percent will fail to submit a valid entry. It will crash, or be a Windows build, or have porn in the title screen, or something like that. People who basically didn’t do their due diligence before submitting in the first place.

That leaves about five percent of the registrations actually producing valid entries. That’s an A at any school in the world. If you submit a valid entry, you get an A. It’s that simple.

Do you get any money for it? No. Do you get any special benefit from it? No. But you got an A, and when you go apply for that job at your local game company, they don’t care about any grade you got for anything that wasn’t game-related. Having a valid entry in DBP gives you an A, and while it won’t get you as much recognition as other game-related activities, it’s a whole lot better than the big fat jack squat most of the other applicants for that job will have.

So just enter! There’s nothing to lose, and much to gain. If nothing else, you’ll get a free four months of premium CC membership.

I didn’t like Braid. I really, really, REALLY didn’t like Braid. It’s the whole “understanding” concept, which when you really come down to it is just the developer saying “think like I do, and you can succeed”. I just fundamentally rebel against that idea, which violates the principle of expressive fertility (Hal Barwood and J.C. Lawrence have both expressed this principle in slightly different ways), and turns the entire game into what feels like a bondage-and-discipline game where the goal is simple subjugation and submission of the player.

I find this to be a shocking and horrible development in modern gaming, and anyone who follows this model with the intent of “taking it to the next level” - a common goal in development; the same thing, but more of it - is moving beyond the unethical into the outright immoral. It is not merely an encouragement of irresponsibility, but an active extermination of individuality and creativity.

This is not in any way intended to be a slam on Jonathan Blow’s desire to drive gaming in new directions and provide experimental types of games, nor am I saying that Braid should never have been made. Any defense of individuality must accept that individuals will frequently want things and do things that are distasteful to others, and those things may even be seen as desirable by large groups of people. It can be productively argued that if nobody hates your game, your game doesn’t have any real merit in the first place, and Jonathan has certainly opened a valuable discussion. He injects great insight to that discussion, and asks valid questions that drive the seeking of valid answers.

When you turn from playing Braid to reading Jonathan’s elucidation of the principles behind it, you find the very opposite of how I see Braid itself: he encourages creativity and individuality, calling for developers to display more of both.

Jonathan’s most incisive statement (IMO) has been the basic truth that WoW is not a good game, that it has gone too far. I entirely agree with that; I don’t like WoW either, but for very different reasons. What Braid demonstrates to me is that it is every bit as possible to go too far in the other direction, and every bit as bad for the industry as a whole. If most game developers were trying to make something like Braid instead of something like WoW, and there are certainly many people pointing at Braid as an inspiration, things would still suck. The real lesson - and I think Jonathan would agree - is that what really sucks isn’t what game you’re chasing, but the idea of chasing someone else’s game at all. When all the games are variations on the same theme, whether they’re all MMOs or all RTS or all Braid, there is simply not enough variance in the population.

The principle of expressive fertility applies: there must be many kinds of games with many kinds of gameplay. There must be games like Braid, and there must be games like WoW, and there must be games like Tetris (yet another game I don’t like), and all the spaces in between. You can’t eliminate the games that suck, because your opinion is no better or worse than mine - and we’ll never agree completely on which games suck.

Railgun, my entry for the Dream-Build-Play competition, is beginning to look almost complete. Moving into Beta stage, the new setup is available for download if you’d like to have a look. Again, the setup must be run as Administrator on Vista, and the new build does not currently support any input method other than the XBox 360 controller.

Gameplay at level 1: average level completion under two minutes

The following things remain to be done from a code standpoint:

• Statistics screen for accuracy calculation between levels
• Start screen and better “active player” handling, per MS best practices
• Save/load game and “time warp” implementation
• Address color-sensitive gameplay for colorblind players
• Volume sliders for music and sound effects
• Color configuration dialogs; better default colors, color scheme settings
• Video options: brightness, contrast, gamma
• Controller sensitivity option
• Quit confirmation dialog looks terrible; redesign
• Mouse and keyboard input for PC build

The bottom half of this list could be discarded if anything horrible gets in the way and something has to go, but I don’t see that happening in the next two weeks.

In addition, the music tracks will be replaced once code changes are complete. There are currently not enough different music tracks, and they’re just basic drum loops. The new music tracks will include drums and synth, much like the music heard in the menu, and several dozen will be included.

As mentioned in the previous entry on this topic, the next four concepts are the core of object oriented programming, and they tend to revolve around the idea of reusing code you’ve already written. As you write code, you’ll find yourself doing the same sorts of things over and over, and the code for your current project will frequently look a lot like the code for the last one. Object oriented programming is intended to make it easier for you to take the code from that last project and move it to your current one, with a reasonable assurance that it’s going to work. This revolves around four primary concepts, which apply to programming elements called classes.

The first concept is abstraction. This is the separation of what you are doing from how it is done. When you define an object, instead of concerning yourself with how things are done, you think primarily about what things you are going to do. A “Sandwich” class should not have any idea what kind of sandwich you are making; it should be capable of being any kind of sandwich. It might understand that a sandwich has bread and filling, that it may be cut, and that it may be eaten - but the details of this would depend on the sandwich.

The second concept is inheritance. This is the idea that objects move from generic types to specific types - you might create a “TurkeySandwich” class which is derived from your “Sandwich” class. Because it inherits all of the properties of a Sandwich, the only thing you have to add to your TurkeySandwich class is the things that only a turkey sandwich would have. All the existing things that a sandwich has and does are automatically included in your turkey sandwich.

The third concept is encapsulation. One of the things your Sandwich class undoubtedly includes is some idea of bread, but a sandwich is not a specific type of bread. Instead, it includes bread, so your Sandwich would not be derived from the Bread class - it would instead encapsulate objects of the Bread class within itself.

The fourth and final concept is polymorphism. This is the idea that any class may be treated as any of its base classes, so when you have a “WholeWheatBread” class which is derived from your “Bread” class, you can put it into your “Sandwich” objects without needing to do anything special. The Sandwich doesn’t care what kind of bread it is; it only cares that you have some type of Bread, so even if your Sandwich class was created long before your WholeWheatBread class, you can still use WholeWheatBread in a Sandwich… or in a TurkeySandwich.  

This can be a little confusing, so later installments in this series will include some example code revolving around the idea of building an object model for sandwiches.