I worked on minor touch ups and bug fixing these past two days. They’re nothing major but still important things that need to be done. At this point, I’m focusing on creating more content. I have levels 1-20 complete and I’m planning on having 50 levels. Each level consists of 5 puzzles, so that’s about 150 puzzles left to create. I’m going to try and pace myself at 2 levels a day.
I can happily say that the majority of all the sound effects are now in the game. I used both Mixcraft 5 and SFXR to create my sound effects. Mixcraft 5 was really nice to work with when I was experimenting with creating my own music. However, that didn’t turn out too well :P. Instead, I’ve been searching for music that would fit well in my game (I have some in mind, and am currently figuring out licensing). I did manage to use Mixcraft for a lot of the sound effects you’ll hear in the various menus. For game play, all the sound effects generated were created from SFXR. It’s an excellent tool that can create random sound effects. You can also manipulate the various sliders to get the sound effect you’re looking for. At first, I thought I’d just use it to generate placeholder sound effects, but I ended up liking it so much that I might just keep the sound effects I generated today in the final product.
Sometimes, you think you have a good idea until you see it in game. I thought I’d instill some life into the puzzles by having the puzzles in the background float around or do a little dance when they were completed. Turns out it’s really distracting and takes the player’s attention away from the main puzzle they’re trying to solve, so I decided to scrap it.
The other thing I worked on recently was adding some more visual feedback for when the user completes a level. Check it out:
Note: Sound Effects are all placeholders at the moment.
I really wanted the game to celebrate and give positive feedback to the user for their accomplishment of clearing a whole level. I do this by adding a nice puzzle rotation/ re-orientation with a camera-zoom effect after the last puzzle in the level is cleared. I think it gives the gamer a moment to take in what they just cleared. On the Level Clear Screen, I’ve added a fireworks display using the same particle system I just finished last week. I also have the stars ‘pop’ in to make it more clear that you are earning stars for your performance. One complaint I have when I play Angry Birds is that it’s not transparent what score you have to aim for to get 3 stars. You can’t see how far away you are from acquiring that next star.
As a result, I wanted to make it clear that you get 1 star for clearing a level, another star for clearing it under the target time, and a third star for not using a single missile. This data is also saved and displayed/reinforced on the Level Selection Screen. When you don’t meet the requirements for a star, you don’t get the fireworks display and instead you get a sad looking star. See how sad he is
Hopefully this will motivate players to come back and try to clear the level with 3 stars
For Christmas, my family got me the Intel 120GB X25-M SSD. I didn’t have time to install it and all my programs until this weekend. It is blazingly fast! Compile times aren’t even noticeable. Everything just seems snappier
When I upgraded to XNA 4.0 my particle system broke because point sprites were no longer supported. Shawn Hargreaves explains why they were removed in this article. I added the particle system early on when I didn’t really have the look and feel of my game well defined. It was something I had already created in another project so it was easy to port over. Explosions consisted of a bunch of points with random directions and velocities emerging from a single origin.
With the upgrade to XNA 4.0, it forced me to not only rewrite parts of the system, but also gave me a chance to update the look of the explosions to match with my current game aesthetics. Here are the new explosions in game:
My goal with the explosions was to create the impression that the blocks were exploding into a bunch of visible pixel blocks. I replaced the points with quads of varying sizes and colours. I also added collision detection with particles against blocks. The particles reflect their direction vector based on the surface normal when a collision occurs, but there is still some wonky behavior during puzzle rotation collisions that I may work out later on. Anyways, I’m pretty happy with the end result.
Lately I’ve been adding a lot more visual feedback for the user. In my game, “the goal is to place all the blocks in the proper places in order to complete the picture”. One particular problem I wanted to deal with was that the “Mistake” block didn’t seem like much of a mistake to the user. A mistake block is formed when the user places a block incorrectly that should not be a part of the picture. I got the idea of adding the camera shake after playing Fruit Ninja and noticing the camera shake whenever I hit the bomb. It was nice little visual cue to show the negative effects of the bomb. Here it is in my game:
An aural cue should complete the effect to let the user know that mistake blocks are bad.
You’ll notice that that the wing texture has some black fringing around it. It also has the puzzle in the background drawn over it. Strangely enough, I didn’t have these issues in XNA 3.1 because I had correctly manipulated various RenderState properties and enjoyed its magic without fully understanding what it was doing. With XNA 4.0, the RenderState class was replaced with three new state objects, the BlendState, DepthStencilState and RasterizeState. The SamplerState class was also replaced with a SamplerState object but with different behaviour.
The above rendering issues are now fixed. Thanks to XNA 4.0, I now have a stronger understanding of the built-in state objects and how they affect rendering. The fix only required a few lines of code, but it took me a lot of trial and error, research and digging around before figuring it all out. Before rendering my 3D components (which have textures with alpha) I would set the following:
GraphicsDevice.BlendState = BlendState.AlphaBlend;
// Render 3D components
GraphicsDevice.BlendState = BlendState.Opaque;
What I had assumed for the longest time was that the DepthStencilState, RasterizeState and SamplerState would all be in their default states because I had not explicitly changed them and if I had, I would reset them back afterwards. In my game, I also draw 2D objects using SpriteBatch, and what I didn’t realize until I read this article was that SpriteBatch was changing several device states that would mess up the way my 3D objects were being drawn. Always assume nothing! Silly silly me.
I finally have 0 compile errors and the game playable again thanks to a lot of the blogs out there that have already gone through this ordeal. I found Shawn Hargreaves Blog to be extremely helpful. Not only does he go through most of the changes from XNA 3.1 to 4.0, but he also explains why those changes were made. It really helped me fix the numerous compile errors I was getting. He sums up why so many changes were made with a simple quote from Banjobeni, “If you break it, break it good”. Another link I found helpful was Nelxon’s XNA 3.1 to XNA 4.0 Chear Sheet. For everything else, Google and MSDN.
I haven’t emerged completely unscathed though. I did have to rewrite major parts of my Save-Load system as well as parts of my custom vertices and FX files. My particle explosions are currently broken because PointLists are no longer supported and I currently have several objects that aren’t correctly rendering. It will probably take another day’s worth of work to get it all sorted out.
I’m currently on XNA 3.1. After February 7th, Xbox LIVE Indie Games won’t be accepting any XNA 3.1 games. As a result, today I’ll be updating to XNA 4.0 as well as switching to Visual Studio 2010. I’ve been postponing this update for awhile because the first time I attempted this upgrade awhile back I ran into a lot of problems/headaches and just decided to stick with XNA 3.1.
I barely managed to get any work done while visiting family in Winnipeg over the holidays. However I did get more fresh eyes on the game and even more feedback. Now it’s time to cram. My personal goal is to have this game completed by the end of February. That gives me 2 months to finish puzzle content, add better sound effects/background music, polish visual effects and bug fixing.