Future of XNA…

A month or so ago the official XNA site, the Creators Club, got a new redesign. It re-launched 80% focused on Windows 7 Mobile development and about 20% XNA indie games.

Then, last week, the new Xbox dashboard launched. It appears indie games are no longer considered ‘games’. Microsoft has opted to file the XNA indie games under the ‘Specialty Shop’ category, along with Avatar clothes and Music downloads. As a result, (according to the community’s official sales numbers), purchases are down 50% and trial downloads are down 75%.

Soon, but still at an undefined time, Game Studio 4.0 will be released. The upgrades and changes to the Game Studio are also centered around Windows 7 mobile.

Torque, the only 3d engine that currently supports XNA has announced the next version of their TorqueX engine will be centered around Windows mobile development and that they “haven’t decided yet what their plans are for Game Studio 4.0 support”.

All these things have the XNA community up in arms, which has further effects.

Several of the better, more well-known developers/companies have officially stated they’re moving on from XNA to Steam or iPhone development. The shift in the sale figures simply isn’t worth the cost of development. This coming from the makers of “Beat Hazard” and other top 20 selling XNA games. *A funny side note…they’ve specifically said they WON’T be doing Windows7 mobile development.

Arkedo, makers of some of the most polished professional games in XNA “JUMP!”, “SWAP”, and “PIXEL” haven’t released a game for XNA in nearly a year. I think it’s pretty safe to say they’re done.

So, take out a lot of the best developers and best games on the platform…well…if you thought there were a lot of massage games, clocks and fireplaces in the past….just wait.

What effect does this have on “Deep Blue”? Well, since I started this project with no real hopes of actually LAUNCHING the game on XNA, much less making a lot of money with it…it’s not going to effect it at all with any luck. I’m far enough along that launching it shouldn’t be a problem, and even with dwindling sales figures I would hope to at least make my $99 investment for the creators club…oh…excuse me…Windows App Dev subscription cost back. With any luck…it will make enough for me to purchase a Unity license and take my C# knowledge there.

It’s just disappointing that it appears the future of such a great program, or at least concept, may be fading away.

Sprite Batch Optimizations

At this point of the process, with all the game play testing going on, I’m scanning the game for signs of things that make the frame rate hiccup. And at the same time I’m actually trying to break it with some of the test levels.

The good news is there’s just a few places where I’m seeing the frames skip a beat. So I headed over to the XNA….sorry…the “App Hub” boards and browse for optimization tips.

Turns out it’s best to keep a minimum number of sprite batch begin() and end() calls, as each one hits the performance a little. Good to know.

However, the bad news is, as far as I can tell. Certain things require new sprite batch calls to be executed and are unavoidable. Things like a change in the blend mode, or a pixel shader that uses a render to texture effect for an effect on the entire screen.

So, I spent some time last night scanning through all the draw statements and looking for ways to cut corners. I did catch one spot where I ended up drawing two copies of all the projectiles on top of themselves….which I wouldn’t recommend. And I think I caught one or two other places where I could merge a couple of sprite batches. But all-in-all, things were pretty tight.

I guess I’ll have to look somewhere else to untie my little performance knots.

Anyway….I just wanted to note. Since I misunderstood some earlier statements about sprite batches. Not only to you want to keep the number of sprite batches to a minimum, it’s ALSO the begin() and end() calls that slow things down a bit.

New Enemy Tests

I’m very pleased to say I’ve got the initial tests for a new enemy type in the game. It’s an enemy that turns the color of the water, making it virtually invisible. That is until you shot him at which point he “decloaks”.

This will make the “shotgun” firing mode much more effective/essential when facing levels with a lot of these creatures.

The cool thing is I was able to pull of the cloaking/decloaking effect with pixel shaders.

So far it’s turned out very well, hopefully I’ll be able to post some video soon.

Video Intro Test - *Check*

It’s a long weekend, Labor Day. And it’s been a pretty productive one.  You may even say I’ve been “on a roll” (I should probably find some wood to knock on).

Load/Save
I’ve created a custom data class for save game data and successfully saved the data with an initial “hit S to save” test. Obviously, not the final method but still…a good first test.

Video Playback
This one actually went a lot smoother than I’d ever imagined given the amount of steps and specifics of it. Anyhow, I created a test video several seconds long, exported it, imported into Deep Blue and even hooked up inputs for a smooth audio and video fade to black when the player ‘skips’ the video.

I think I’ll probably still have to tweek the code so it doesn’t stretch when going to alternate resolutions (right now it’s filling the screen by grabbing the dimensions of the viewport), but that shouldn’t cause any problems.

New Enemy Attack Effect
The storyline of Deep Blue has these gigantic jellyfish that are electrically charged. The warnings are that coming into contact with said jellyfish could potentially short out the MANTA.

So, now when the player’s ship hits a jellyfish the player loses the ability to control his ship for 5 seconds. This is indicated visually by the lights on the ship going out.

It seems to have worked out pretty well and definitely is a hazard for the player.

Play, Play, Play
The core game mechanics are all in now and (it seems) working properly. So now it’s time to play. Serious game play testing has begun time to see how people react, how the play feels and adjust the overall game attributes and see if there’s too little, or too much.

Marine Superpower Poll

Time for a quick poll. There are so many crazy abilities that deep sea creatures have...if you had a wish, which ability would you want?

Online Surveys & Market Research

Interpolation Success!

I’m VERY HAPPY to say, especially after this weekend’s problems that I seem to be getting the hang of this basic Interpolator class stuff.

It’s working like a charm for the logo and splash pages and really makes a big difference in the presentation. I never did have the intro screens working quite right and now things are looking pretty sharp.

It’s too late here to keep moving forward tonight so I’m off to bed, but hopefully tomorrow I’ll be able to finish up the screen interpolations and hopefully start diving into the timer upgrade throughout the rest of the game.

On a minor note, I’ve also been chipping away at the new game art and UI.

Much Calmer Now

Ok, after saying “To heck with it!”, and '”it” being Visual Studio 2008, 2010, and any kind of converter, and any way to create a new project…I gave creating a new project one last shot which resulted in the same apparent lock up as all the other attempts before. The difference is, this time I was so frustrated I left it ‘locked up’ and walked away to do something else on another computer.

Wouldn’t you know 3 minutes later Visual Studio 2008 decided it had thought long enough about creating a new project and…did. So I saved out that new project as a timer and interpolator test project to play around with and got back to important stuff…like playing Starcraft II.

So I had plenty of time to cool down after the 2 hours or so of completely wasted time earlier today, and I was able to go through Nick G’s tutorial in a breeze.

I’m pretty sure that system is the better way to go so the next step is to go back and try implementing it again in “Deep Blue”.

The bad news is the real possibility that I could be in serious trouble if I HAVE to upgrade “Deep Blue” to a Visual Studio 2010 project…since still, only one file successfully converted.

Hopefully I can finish it before the Visual Studio 2010 project becomes a requirement.

Full Circle

Super. The good news I guess is that I didn’t lose any code for Deep Blue in all that conversion/backup nonsense. The bad news is that I’ve now come full circle and am now where I was a few hours ago. VS 2008 opens and runs Deep Blue, and I’m unable to create a new project.

Awesome. 

I think I’m done for a while. Enough wasted time.

Upgrade Fail

After installing Visual Studio Express 2010 I tried to open “Deep Blue’s” project which instantly starts the “project update” import function.

I’m annoyed to report that apparently only one file in the entire project successfully converted.

The good news: I found an installer still on my hard drive for Visual Studio 2008 and I’m reinstalling that again to see if I can open the project and hopefully create a new project after that test.

It couldn’t be easy could it.

Studio Express Update Day

Well, a little unexpected, but it looks like today is Visual Studio Express Upgrade day. In attempting to follow Nick G’s tutorial on using the timer and interpolator class I’ve suddenly come to discover that my version of Visual Studio Express (2008 version for the record), has rebeled and refuses to create a new project.

Cute.

I tried the ‘repair’ feature in Windows…and that hasn’t helped. Sooooo, I’m currently downloading and installing Visual Studio 2010 and crossing my fingers that there aren’t major upgrade difficulties with existing projects.

Don’t let the fact that I started “Deep Blue” with Visual Studio 2005 give the illusion that the dev time has taken longer than it actually has. Granted….it’s take much longer than I’d originally thought…but not 5 years.

Timer Trouble

Ugh, this new timer and interpolation thing is giving me troubles. Initially I wasn’t even interested in a new timer class. My timer class was working just fine. The problem is Nick’s new and improved interpolation class comes with requires a new and improved timer class.

Of course getting the new timer to not shatter the code that the rest of the game was using for a timer has been, problematic at best. And I haven’t even actually begun to start messing with the interpolation class yet.

Since I don’t see it as good practice to have two timer classes in a program I’m faced with one of two choices. Either rewrite the rest of the game elements that currently access my timer class to use the new timer class. Or, rewrite parts of the new timer class to accept the calls that are currently in the existing game.

The one good thing coming out of all of this is the educational value of it since I’m starting to get into delegates and lambda expressions which is new stuff to me.

Tweening...stuff

I'm happy to report the further animation and collision tests have turned out positive, so with the new classes in place it's time to move on to the next thing. And after throwing a dart at the wall...it appears working in an interpolation class (or tweening class) is the next thing to tackle.

This interpolation class will be a utility class that will handle things like fading the screens up and down, moving menu items across the screen and who knows what else. So it will be a very handy thing to have around both now and in the future...so, let's get it right.

To start off I've been reading a lot from Nick Gravelyn's blog. And lucky for me he has an interpolation class that will serve as my base point of learning. You think that would be easy then huh? Well it appears I've got some reading up to do before I get rolling with it since Nick's using delgates and lambda expressions to implement his classes.

So for now I've got to get a handle on these two new elements...so, back to reading.

New Animation System in Place

Initial tests indicate that I may have finally gotten the new animation system working properly...did I mention I'm not very good with math. Anyhow, as an added bonus it appears, believe it or not, that the collision system may be working as well. (I never saw that coming, but I'm not complaining.). But those are VERY initial tests in both cases.

So here's a brief history of the animation system throughout Deep Blue's development.

I. Square Sprites - The initial system was gleaned from the platformer demo in the Visual Studio Express Dev Library. It was the most specific, and limiting of all. It ONLY accounted for square sprite frames (with a 1:1 ratio) layed out in a horizontal line. While this may have worked perfectly and been very efficient for the platformer, you can imagine the limitations it put on sprite design.

II. Variable Ratio Sprites - So, the first thing I did was overload the method with an alternate version that accepted a frame width. I kept the sprites aligned in a horizontal row so that the frame height could be simply pulled from the sprite texture height.

That worked pretty well, except on the larger sprite animations which resulted in extremely long sprites (250 pixel wide frame * 30 frames = 7500 pixel wide sprite). And that just wasn't going to work. Even though it wasn't recommended, things animated pretty well....until the engine started checking for pixel collisions on a sprite of that size. It pretty much brought the game to 2 to 3 frames per second. So after posting and talking with the helpful crew on the XNA forums they suggested a basic rule that no sprite should be larger than 2048 in any dimension, and really, you should shoot for a 1024 max in most cases.

In order for that to happen...other than reducing all my larger animations to 3 frames....I had to lay out the frames in a square spritesheet.

III. Square Sprite Sheets - So my current solution is to lay out the frames in a 1:1 ratio sprite sheet with a max size of 2048 x 2048 pixels using a 1024 x 1024 texture when possible. After loooooooooots of broken math it appears to be working. So now I can have much more efficient sprite sheets and much better frame rates when lots of things are moving on the screen at once.

Each of the above variations was carried out by overloading the same Animation constructor so if I HAPPEN to have an animation that has 1:1 frames that is not over 2048 pixels in texture size I can create it easier than I can the custom square sprite sheet constructor.

All-in-all I'm pretty pleased with the results. It took a little longer than I'd hoped to figure it out, and I went through a bottle of Tylenol in the process but I'm glad to have it out of the way.

Let the Music begin.

It's a little early, but I did get my little music studio up and running. It's a little awkward at the moment. The distance between my computer keyboard and monitor and the digital piano is far enough to remind me how old I'm getting.

Eventually we'll plan on mounting a second monitor in front of the piano but for now it just makes recording things a little more interesting.

The good news, everything is in working order and it's fun to be recording again.

Recent Progress

Things have been moving along pretty well from the programming side. Recently, with a little guidance from "fr3shm4nt" on the XNA forums, I was able to get a HLSL shader working that included a lightmap for darkening the scene the deeper you dove. That was a pretty big step and I'll use some of the same techniques for the radial blast distortion when I get to that.

As things got darker deep underwater I also added the system in place for the bioluminecent glow of some of the enemies. So we should be set there.

I've also done a little tweeking to the treasure system to make it easier to read and apply, as well as cleaned up the animation system a little putting things in more logical places.

I'm still wrestling with the collision system, but refining the animation system was the first part to cleaning that up and getting it working properly.

On top of all the programming I've also been focusing in on the "Deep Blue" story. At this point it's looking pretty solid. The story has been a lot like painting...starting with big broad general strokes slowly refining and watching everything come together.

With all this focus on code and story it hit me recently that the one area that seems to be lagging behind is the art. Anyone else find that as ironic as I do? So anyhow...at some point soon I'll have to turn my attention back to the artistic side of things.

But that should be the easy part....right?

Deeper Blue

The concept of "Deep Blue" began as an underwater submarine game in fact the folder on my drive still bears the original name "Sub Attack". Blue waters with light rays dancing through the scenes. But after seeing a few videos on YouTube about the deep sea creatures I though it would be more interesting for it to take place much deeper in the ocean. And that's when things really started to develop from a creature/vehicle concept.

The only problem, and one that's been really getting to me recently, is the fact that 30,000 feet underwater looks much different than 500 feet underwater. Visibility becomes a major game play element. Even with some of the story elements of Deep Blue that would add a little more light to the scene, the environment would be much different at that depth.

I've decided to shoot for something inbetween reality and game...which seems to be a common approach so far...and go for a much darker environment the deeper you go.

To pull this off, I hope, I'll use a pixel shader to darken the value of the entire screen then use glow textures with an additive value to 'light up' the lights on the MANTA or the bioluminecent creatures of the deep. At least that's the theory.

So far the darkening part seems to be working pretty well, now I've just got add glowing light sources back in. The shader started out as a game component, much like the bloom shader I'm using. But I needed more control over the draw order so the UI and messaging wouldn't be effected by the darkening so I switched it to a class.

Some Days

Is it just me, or does it just seem impossible to program anything that works on some days. Other days things go smoothly, but days like today I can't seem to get my mind to kick into "program" mode.

Multiple Updates

Although I have to admit, Star Trek Online has kept a little distracted from Deep Blue, it hasn't been all photons and phasers.

HLSL Pixel Shaders
Thanks to an XNA video session by Shawn Hargreaves I've started playing around with some simple pixel shaders in Deep Blue. Earlier I used a pixel shader to add a subtle underwater "glow" effect to the game. It looks a little like you've been swimming in a pool that's been a tad over chlorinated, but I like it.

I used a glow shader from the XNA library on the site so getting it in the game was the big accomplishment, however at the time it didn't mean that I had a good understanding...or any understanding of the HLSL programming.

Now, thanks in part to Shawn's tutorial, I've successfully implimented a slight water distortion effect to the game. One unexpected side effect has been the loss of my nice smooth 'fade from black' fade-ins and I'm still trying to track that one down.

The last shader I really want to work in would be a circular ripple distortion effect for ship explosions and the bubble burst weapon.

Weapons System Update
The new weapons system is about 90% in place. There's a couple of final things to work out but it's a much more flexible system than the way I originally approached it. There are now three types of ammo and three types of firing patterns. Each ammotype has it's own O2 cost, trajectory and damage with easy to modify numbers for game balancing.

Pixel Perfect Collisions
AH! And in another "big win" moment, initial tests are positive that I finally got the per pixel collision detection working, both on animated and non-animated sprites. Further testing is needed, but things are looking pretty promising right now.

I probably need to make an updated game video soon to show off all this progress. Possibly after I get in the treasure system.

Weapons Upgrade

Rewriting the weapons system tonight to be more versatile, compact, and modular. Bubble sprites were being loaded in the level class, while the player and enemy classes had code for input, firing and updating...which worked, but was scattered at best.

Weapons are now built with a number of variables (rate of fire, ammo, and barrel location) which makes it easier to mix and match weapon types and projectiles.

The plan is to totally rework the 'weapon' class which had been stripped pretty bare from the last rework. Also the creation of a new 'ammo' class and a couple of new enums to handle the rate of fire and ammo type possibilities.

I still have some wonkiness going on with the per pixel collision detection on animated sprites but that's not surprising since it originated from a tutorial on static sprites. The collision fix comes at a later date.

Inspired By vs. Educational

Last night I did a bit more research on creatures of the deep (thank you interweb, wikipedia and especially the magic of youTube). The good news is there is a LOT of REALLY cool stuff in the deep ocean...I mean the "Blow your mind, you've got to be making this up kinda stuff". For instance, did you know that at 3,000 feet deep, even though it is too deep for sunlight to reach, it is not a pitch black void. It's more a twinkling lightshow similar to the densest lightening bug swarm you've ever seen. Also, the tiny hatchet fish has photocells on it's underside that has the ability to change color to perfectly match the color of the light above him rendering him invisible from below. It's a built in cloaking device.

The bad news is, at the depths I was planning for the game anything not flashing would be pitch black. Which wouldn't make for a very fun game. I really wanted to game to be covertly educational, showing the diverse wildlife of the deep and some of the cool features about those creatures, but it's hard to be educational and blow the creatures away at the same time. Something seems to get lost there.

Result: I'm going to have to take some pretty big creative liberties with the environment and the enemies, and find some way to work in the factoid elements (possibly on each loading screen).

I think I'm also going to assign Katie to factoid research and copyrighting, cause some of these things are too cool and something she needs to discover for herself.

Happy 2010!

So here we are at the beginning of a new year. Development is still moving along, slowly but moving none-the-less. And I continue to feel more familiar with C# and XNA as things progress. Recently in the XBox indie game library a company called Arkedo Studio has been releasing very well produced, high polish, yet relatively simple games. And I mean "simple" in the best way. The games are incredibly easy to pick up and play. Each has it's own cleverness and/or cuteness. And each has it's own look and feel, yet they all manage to maintain a 'family' style about them.

They are, in my opinion, some of the best, most professional games in the indie marketplace. They also are very limited in what they offer. There is no multiplayer, no save, no achievements or awards, and I have yet to see any kind of customization or personalization in the games. They are, in a way, a nod back to the 25 cent arcade days. Drop in a quarter, play till you die then start the thing all over again.

Of course, the down side to that approach (at least for the player) is they get very familiar with the beginning levels which they can grow tired of early. The up side is almost purely on the development side. It's a lot easier to develop a game when you don't have to worry about multiplayer, signing in, save points, etc.

Yet there are games, current games, that live almost entirely in the replayable world. The first that comes to mind is "Left 4 Dead". Sure, there's an initial exploration and discovery phase to the game the first couple of times through, but after that thanks to the dynamic in-game "director" the game retains a very high replay experience.

So, is there a way to combine the developmental efficiency of Arkedo Studio's "simple" approach with the dynamic replay value of Left 4 Dead? It might be a variation in weapons, ammo, level layout, depth (water), or a variety of other levers and switches