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.
Showing posts with label Deep Blue. Show all posts
Showing posts with label Deep Blue. Show all posts
Thursday, July 22, 2010
Wednesday, June 2, 2010
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?
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?
Saturday, May 8, 2010
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.
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.
Tuesday, February 23, 2010
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.
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.
Tuesday, January 5, 2010
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.
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.
Monday, January 4, 2010
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.
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.
Sunday, January 3, 2010
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
Sunday, December 27, 2009
Over a Year
Well, it's been a little over a year since I started development of "Deep Blue". And yes, it's true I sorta figured I'd be well on with my second game by now but I can't say it hasn't been worthwhile.
In the past year I've taken big steps in learning C#, the XNA development platform, as well as the basics of object oriented programming. I've read through 2 books on C# programming, 2 additional books that deal with C# programming specifically in XNA. I've done my fair share of tutorials, studied code from over a dozen other games. I've built a working version of "Deep Blue", then torn it down again to make a much more efficient version. All this in my 'free time'.
All in all, it's been a productive year, even if the game isn't launched yet. We'll see what 2010 holds. And yes, I'm crossing my fingers once again that the launch of Deep Blue is in there somewhere.
In the past year I've taken big steps in learning C#, the XNA development platform, as well as the basics of object oriented programming. I've read through 2 books on C# programming, 2 additional books that deal with C# programming specifically in XNA. I've done my fair share of tutorials, studied code from over a dozen other games. I've built a working version of "Deep Blue", then torn it down again to make a much more efficient version. All this in my 'free time'.
All in all, it's been a productive year, even if the game isn't launched yet. We'll see what 2010 holds. And yes, I'm crossing my fingers once again that the launch of Deep Blue is in there somewhere.
Tuesday, December 15, 2009
Back Up And Running
Thanks to my wonderful in-house tech support department (a.k.a. my wife) I'm back up and running with a completely fresh and new hard drive and no viruses.
I successfully have both rectangle vs rectangle collision detection as well as per pixel collision detection test working in-game. Now to get the per pixel working while a rotate transform is taking place, so everything checks out with the spinning O2 tank.
I've also gone back and reworked the animation and animation player classes. They were designed with the assumption that all sprites would be squares which is not the case, pretty much across the board in "Deep Blue". But I still have another modification to make to it so my animation sprite sheets are not required to be laid out completely horizontally...like in the platformer sample.
So, more to do, but stuff is blowing up now and that's usually a good thing.
I successfully have both rectangle vs rectangle collision detection as well as per pixel collision detection test working in-game. Now to get the per pixel working while a rotate transform is taking place, so everything checks out with the spinning O2 tank.
I've also gone back and reworked the animation and animation player classes. They were designed with the assumption that all sprites would be squares which is not the case, pretty much across the board in "Deep Blue". But I still have another modification to make to it so my animation sprite sheets are not required to be laid out completely horizontally...like in the platformer sample.
So, more to do, but stuff is blowing up now and that's usually a good thing.
Tuesday, November 10, 2009
Version Problem Solved...sort of
It took a bit more browsing through the XNA forums to find a 'solution' to my XACT audio problem. Here are a few important things to note.
First, the 'version' of the project is not entirely dictated by the 'version' of Visual Studio that you're currently using. The project is versioned when you start the project. I began "Deep Blue" with Game Studio 2.0 but then upgraded to 3.0 when it was mandated by the rules.
The problem with that is that XACT 3.0 wasn't compatible with Game Studio 3.0...even though they were a part of the same download...mmm...yeah....but anyhow. They fixed the compatibility issue with Game Studio 3.1 so I upgraded my version of Game Studio. But that didn't mean I upgraded the project...which remained at version 3.0, even though I was developing it in 3.1 at the time. So I had to manually 'upgrade' my project to 3.1.
Solved.....right? Not quite.
Even after doing this I got some really odd version errors on the audio so I decided to open XACT 3.0 and rebuild the sound banks again. But that didn't seem to help. I confirmed that the files were being overwritten (updated), but it didn't seem to have any effect.
I had to manually delete the compiled sound bank files and THEN rebuild the sound banks to finally get the project to compile without error. So now it all works, but it still doesn't make much sense.
First, the 'version' of the project is not entirely dictated by the 'version' of Visual Studio that you're currently using. The project is versioned when you start the project. I began "Deep Blue" with Game Studio 2.0 but then upgraded to 3.0 when it was mandated by the rules.
The problem with that is that XACT 3.0 wasn't compatible with Game Studio 3.0...even though they were a part of the same download...mmm...yeah....but anyhow. They fixed the compatibility issue with Game Studio 3.1 so I upgraded my version of Game Studio. But that didn't mean I upgraded the project...which remained at version 3.0, even though I was developing it in 3.1 at the time. So I had to manually 'upgrade' my project to 3.1.
Solved.....right? Not quite.
Even after doing this I got some really odd version errors on the audio so I decided to open XACT 3.0 and rebuild the sound banks again. But that didn't seem to help. I confirmed that the files were being overwritten (updated), but it didn't seem to have any effect.
I had to manually delete the compiled sound bank files and THEN rebuild the sound banks to finally get the project to compile without error. So now it all works, but it still doesn't make much sense.
Sunday, November 8, 2009
Version Problems...
See, and I was going to make this post about how cool and awesome the XACT audio tool was for sound engineering. But instead, this post is about how screwy version control and backwards compatibility can be.
I'm having some odd version problems with XACT and Game Studio 2.0 or 3.0 (it's hard to tell which is causing the problems). The XACT audio tool is what enables you to create sound banks for XNA games.
At this point, one solution (sort of) appears to be to make a new sound bank with all the sounds in it. Which believe it or not is a little more complex than simply including a bunch of wav files in one collection. And honestly, that was supposed to be the 'cool' part...unless I have to do the whole thing twice.
Bottom line...or as much as I can tell right now...is that I began this project with Game Studio 2.0, which came with the XACT 2.0 tool. Then I had to upgrade to Game Studio 3.0 (all XNA submissions must be in 3.0 at this time). Well Game Studio 3.0 came with the XACT 3.0 audio tool...HOWEVER...the 3.0 audio tool was not compatible with Game Studio 3.0. (Yeah, I have no idea how THAT passed any kind of QA). This is an error they fixed in Game Studio 3.1. So you'd think everything would be cool (now). But it looks like (judging from the XNA forums), that if you start a project with an older version of Game Studio...it won't accept newer file format of XACT.
Ok, so worst case is that I have to recreate all the audio I just finished in XACT 3.0....back in the 2.0 version since any sound bank created with XACT 2.0 seems to work fine. ACCEPT for the funny thing call the XACT auditioning tool which is another app that runs in the background along with XACT that enables you to listen to the sounds you're creating in XACT. Without the auditioning tool...you can't hear a single thing of what you're creating. The totally cool and awesome part now is...the 3.0 version of the auditioning tool deleted/overwrote the 2.0 version. So now, if I try to use the XACT 2.0 tool to recreate the sounds....I can't listen to a single thing I'm doing.
So....a bit stuck on audio at the moment. Still searching the forums for a better answer than the one I've found so far.
I'm having some odd version problems with XACT and Game Studio 2.0 or 3.0 (it's hard to tell which is causing the problems). The XACT audio tool is what enables you to create sound banks for XNA games.
At this point, one solution (sort of) appears to be to make a new sound bank with all the sounds in it. Which believe it or not is a little more complex than simply including a bunch of wav files in one collection. And honestly, that was supposed to be the 'cool' part...unless I have to do the whole thing twice.
Bottom line...or as much as I can tell right now...is that I began this project with Game Studio 2.0, which came with the XACT 2.0 tool. Then I had to upgrade to Game Studio 3.0 (all XNA submissions must be in 3.0 at this time). Well Game Studio 3.0 came with the XACT 3.0 audio tool...HOWEVER...the 3.0 audio tool was not compatible with Game Studio 3.0. (Yeah, I have no idea how THAT passed any kind of QA). This is an error they fixed in Game Studio 3.1. So you'd think everything would be cool (now). But it looks like (judging from the XNA forums), that if you start a project with an older version of Game Studio...it won't accept newer file format of XACT.
Ok, so worst case is that I have to recreate all the audio I just finished in XACT 3.0....back in the 2.0 version since any sound bank created with XACT 2.0 seems to work fine. ACCEPT for the funny thing call the XACT auditioning tool which is another app that runs in the background along with XACT that enables you to listen to the sounds you're creating in XACT. Without the auditioning tool...you can't hear a single thing of what you're creating. The totally cool and awesome part now is...the 3.0 version of the auditioning tool deleted/overwrote the 2.0 version. So now, if I try to use the XACT 2.0 tool to recreate the sounds....I can't listen to a single thing I'm doing.
So....a bit stuck on audio at the moment. Still searching the forums for a better answer than the one I've found so far.
Saturday, November 7, 2009
My First Game Component
I'm very pleased to say I've completed my first independent Game Component. I created a messaging system for common message types. So far that includes floating score bubbles and sinking messages that I'll use in "Deep Blue" for things like "Ready, Dive!" or "Level 1".
It's a message system that is complete independent of the rest of the game code. It's easily integrated into any future game with....I think 2 lines of code. It's also something I can easily build new message types into with simple additional classes.
Things are moving along pretty well.
It's a message system that is complete independent of the rest of the game code. It's easily integrated into any future game with....I think 2 lines of code. It's also something I can easily build new message types into with simple additional classes.
Things are moving along pretty well.
Friday, October 23, 2009
To Multiplay, Or Not To Multiplay
Currently weighing the value and use of multiplayer in "Deep Blue". Does it make sense? What does it add (if anything)? What does it require? What does it take away? Is there a "gotta have" reason for it?
Ever since early on in the play testing process Connor made the request for multiplayer. However, since this was my first shot into XNA and C# the best I've been shooting for at this point was couch play with two player co-op in two MANTA subs. Couch play seemed only logical since, barring some incredible miracle, I don't see "Deep Blue" having enough concurrent game plays to support a XBox Live multiplayer mode.
But the domino effect of including simple couch play will be felt throughout the game. How do we allow two players in the water and still have a balanced game that isn't twice as easy with two people? Then there's the whole process of registering two controllers and possibly two XBox Live accounts. Some of the UI elements (like showing the current depth) become confusing with two players.
At this point I think I'd rather toss multiplayer this time around and possibly use that time to create an awards/achievement system and more story elements.
I guess I'll run it past the game design boss, Connor, and see if he'll let it go. I just don't want to add multiplayer if it doesn't truely add something to the game play. Having it just to have it, does not increase the fun.
Ever since early on in the play testing process Connor made the request for multiplayer. However, since this was my first shot into XNA and C# the best I've been shooting for at this point was couch play with two player co-op in two MANTA subs. Couch play seemed only logical since, barring some incredible miracle, I don't see "Deep Blue" having enough concurrent game plays to support a XBox Live multiplayer mode.
But the domino effect of including simple couch play will be felt throughout the game. How do we allow two players in the water and still have a balanced game that isn't twice as easy with two people? Then there's the whole process of registering two controllers and possibly two XBox Live accounts. Some of the UI elements (like showing the current depth) become confusing with two players.
At this point I think I'd rather toss multiplayer this time around and possibly use that time to create an awards/achievement system and more story elements.
I guess I'll run it past the game design boss, Connor, and see if he'll let it go. I just don't want to add multiplayer if it doesn't truely add something to the game play. Having it just to have it, does not increase the fun.
Monday, October 12, 2009
October Video Update
Here's a quick look* at how things stand. Obviously the new collision detection isn't in and I had made a noob mistake while rendering the latest rammer enemy which left the annoying light halo around the outter edge of the ship.
See the few previous posts for a short breakdown of what is new and/or changed.
Anyhow, progress is being made. More to come.
(* Facebook folks may have to follow the link: http://deepbluexna.blogspot.com )
Connor the Game Designer
Now that I've got a level system in place for "Deep Blue" I introduced Connor to the level editor, basically just a .txt file inside Studio Express. I laid out the rules for him of what each level needed to be valid and showed him how to do a build so he could test. So I put him in the role of both level designer and head of Q.A.
And here's Connor working on very intense level design.
And here's Connor working on very intense level design.
....followed only moments later by Connor explaining to me all the things that were wrong.
Yes..."Deep Blue" still has a long way to go.
He's ALIVE!!!!
Sorry, I couldn't resist. I'm referring to the enemy ships that are now animated (swimming). I used the "Sample Platformer" game that came with Studio Express as a base for the sprite animation system.
Even better, using the level system I've got enemy placement in the level with multiple enemy types, one animated and one non-animated. So now I guess I'd better get to work on working in a few more enemy types to play with.
I've got Connor working hard on level design, he's working in Studio Express on a .txt file for enemy placement. He's going through all the create/test/alter cycle to get things the way he wants them.
Hopefully I'll get a video up soon to show progress.
Even better, using the level system I've got enemy placement in the level with multiple enemy types, one animated and one non-animated. So now I guess I'd better get to work on working in a few more enemy types to play with.
I've got Connor working hard on level design, he's working in Studio Express on a .txt file for enemy placement. He's going through all the create/test/alter cycle to get things the way he wants them.
Hopefully I'll get a video up soon to show progress.
Sunday, October 4, 2009
Deep Blue 2.0
Things are moving pretty well with the restructuring. Here's a list of some of the changes, both big and small.
- (new) Logo screen with an image that may be swapped with a video before launched.
- (new functionality) Pop up windows ("How to Play" and "Credits") support multiple pages and an "open/close" state.
- (change) Projectiles are now stored in a List instead of an array to support infinite shots and stop the rubberbanding on the shotgun weapon.
- (new) Level object created, to support actual level design over the random spawn style game. Levels are designed and read in from a .txt file.
- (change) Enemies are now stored in a List instead of an array to support a variable number of enemies per level, as part of the level design change.
- (change) various cleanups of methods and classes.
- (change) and the big change was that the whole system is built in a modular fashion, instead of 90% of the code being found in one file. Individual classes for game screens, pickups, enemies, player, weapons, UI...etc. This was the entire reason for the teardown, so that the code could much more easily be modified for future games. It's also much easier to read through.
Still have a ways to go, but things are headed in the right direction now.
- (new) Logo screen with an image that may be swapped with a video before launched.
- (new functionality) Pop up windows ("How to Play" and "Credits") support multiple pages and an "open/close" state.
- (change) Projectiles are now stored in a List instead of an array to support infinite shots and stop the rubberbanding on the shotgun weapon.
- (new) Level object created, to support actual level design over the random spawn style game. Levels are designed and read in from a .txt file.
- (change) Enemies are now stored in a List instead of an array to support a variable number of enemies per level, as part of the level design change.
- (change) various cleanups of methods and classes.
- (change) and the big change was that the whole system is built in a modular fashion, instead of 90% of the code being found in one file. Individual classes for game screens, pickups, enemies, player, weapons, UI...etc. This was the entire reason for the teardown, so that the code could much more easily be modified for future games. It's also much easier to read through.
Still have a ways to go, but things are headed in the right direction now.
Thursday, October 1, 2009
Making Progress
Mr. Montgomery's solution seems to be working. After commenting code and excluding classes throughout the project "Deep Blue" is up and running again. I've got a logo screen, splash screen, main menu, game over screen, and the beginnings of the main game screen complete with controllable MANTA ship.
The work ahead still looks pretty daunting if I step back and look at the whole thing in it's entirety, but plugging things in one little step at a time hasn't been too bad so far.
I just hope all the extra time it's cost me on "Deep Blue" will be worth it (both for the completion of Deep Blue and for the next game...themed around the same engine).
The work ahead still looks pretty daunting if I step back and look at the whole thing in it's entirety, but plugging things in one little step at a time hasn't been too bad so far.
I just hope all the extra time it's cost me on "Deep Blue" will be worth it (both for the completion of Deep Blue and for the next game...themed around the same engine).
Thursday, September 24, 2009
Back at it, with a new strategy
Ok, so although I've had a rush of other things that have popped up...like Cub Scouts and Scribblenauts...I have to say I've been a little discouraged with "Deep Blue". I had the goal of breaking the game and restructuring it, then putting it back together. Well, I managed to do the first part reeeeaaaally well. Maybe a little too well.
I've had trouble finding a way to approach "fixing" the code. I begun following the flow of the game from the beginning and fixing things that were broken along the way, but with the whole thing a wreck it made it impossible to compile and thus, test.
Then I tried looking at the debug code and fixing things one class at a time, beginning with the class with the least amount of errors. I found it proved very hard to tell if I was making progress or not. Again, without the ability to compile, it's hard to get a good feel for progress.
I THINK the restructuring was going pretty well. It definately cleaned up the main game class a ton, but I had no way to test.
So I spoke with a couple of friends at work skilled in programming and Mr. Jim Montgomery (honestly one of the most impressive sounding names at work, you really have to say the whole thing) suggested commenting virtually everything out in the main game class, just to get the game to compile and slowly turn things on one piece at a time.
So that's was the new plan. Even if I had to comment it down to a blue screen, I was going to get it to run again.
After my initial tests, things seem a little better than the worst case senario...after a ton of commenting I've returned to a logo screen, to a splash screen, to a menu screen (and the menu still works). And now begins the slow process of turning things back on and fixing as I go.
I've had trouble finding a way to approach "fixing" the code. I begun following the flow of the game from the beginning and fixing things that were broken along the way, but with the whole thing a wreck it made it impossible to compile and thus, test.
Then I tried looking at the debug code and fixing things one class at a time, beginning with the class with the least amount of errors. I found it proved very hard to tell if I was making progress or not. Again, without the ability to compile, it's hard to get a good feel for progress.
I THINK the restructuring was going pretty well. It definately cleaned up the main game class a ton, but I had no way to test.
So I spoke with a couple of friends at work skilled in programming and Mr. Jim Montgomery (honestly one of the most impressive sounding names at work, you really have to say the whole thing) suggested commenting virtually everything out in the main game class, just to get the game to compile and slowly turn things on one piece at a time.
So that's was the new plan. Even if I had to comment it down to a blue screen, I was going to get it to run again.
After my initial tests, things seem a little better than the worst case senario...after a ton of commenting I've returned to a logo screen, to a splash screen, to a menu screen (and the menu still works). And now begins the slow process of turning things back on and fixing as I go.
Friday, September 11, 2009
Sucker Shark
Initial 3d model of an enemy tentatively called the "Sucker Shark". They travel in packs, are quick and agile and attach themselves to the players ship sucking the oxygen out of it.
The oversized reflective eye is required for the deep sea low light environment.
Subscribe to:
Posts (Atom)
