Beat Detection System

Well, I've been able to read in raw PCM data from an iPod asset thanks to the iOS 4.1 update we saw over half a year ago. Now, if I could get this beat detection algorithm to work. I'm modeling everything from this article here. The steps to each algorithm were written in a pretty cryptic fashion. To make matters worse, the author's website isn't available anymore, so I won't be able to look at his source code on how he got his results to work.

If I can get this to work, I'd be in business!

The game is really coming together now. No gameplay yet because of the beat detection issues I've been having (getting +3500 beats in a 62-second clip of music). I recently got in-app email working, so users that would like to post feedback to me or the others working on the game can do so conveniently without ever leaving the game!

One other feature I incorporated was this in-app messaging widget that will stall all other input similar to how alerts work in iOS. This really comes in handy when it comes to polishing the UI. I also use it to generate user reviews on the app store. Whenever the player plays for a while, the game will pop up a message asking if the player would like to write a review in the app store. If the player presses "Yes", then the game redirects to the game's page on the app store. The player can also select "Later" to be reminded after another long interval of gameplay, or never be reminded again by pressing "No".

I also have a pricing scheme where my app will be on sale during a certain time of the week indefinitely. I think it's a good idea, and I'll have to post the results I receive if I ever get this game out there.

A New Year, and New Developments

I've been gone for a while, but my efforts as an iOS developer haven't been suffering. There's been a lot of buzz going on with my work:

For starters, I have a new title in production called "Blitz Blok Beatz". It's an iPad-exclusive game similar to its predecessor, Blitz Blok that made its debut for iPhone and iPod Touch in early 2009. As the name implies, "Blitz Blok Beatz" has to do with rhythm-like gameplay with music. I do not have any gameplay to show currently, but it's all starting to come together. I'll have something to put on display here very shortly.

Blitz Blok Beatz will have improvements over the original Blitz Blok in every way. One major issue I had with the first Blitz Blok was my lack of experience in developing full games with different game states, and menus. After finishing Blitz Blok, I started to think up ways to handle transitions between different screens, and how to transition between different game states which hold so much data, that only one game state can be loaded into memory at a single time.

When I first started working on Blitz Blok Beatz in mid-October 2010, I spent about 6 weeks working on new programming paradigms new to me. During this time, I wanted to establish a new menu system that would make creating new game states and screens to menus easy to accomplish. It would also allow me to add new types of game-specific widgets (such as buttons, tables, etc) without having to modify the core menu code. That way, if I wanted to add or drop a screen at a whim, it could be done with ease throughout development. Perhaps all this work in infrastructure this was my way of getting out of planning the game out more thoroughly... but I'm not complaining!

I'll provide a more in-depth explanation of this menu system as a tutorial for making an end-all game menu solution --that'll work for any game. However, not before I introduce you to game states, and how I think they should be used conceptually, and code-wise.

After developing the game state and menu systems, the results have been phenomenal! In my new menu system, I make heavy use of the more intermediate aspects of object-oriented programming (OOP). By taking advantage of C++ inheritance and polymorphism, it really made all the difference. What used to take multiple source files with hundreds of lines of code for a single game state in Blitz Blok now takes about 80 lines to do with fancier transitions and animations.

Other improvements I've made over this short period of time is my website. I rebuilt it from the ground up, and it looks great. You can check it out over at: http://www.truesoftent.com. A little quirky, but over time, it'll be a really sleek-looking site!

Localization is now possible too! I've found this online service built around translating iOS apps for all platforms called iCanLocalize. With my past code, I couldn't render localized text to the screen. Now, though, I have developed a C++ class that will take in an NSString of text, and convert it into an OpenGL texture. This allows me to easily print text to the screen with custom font, display it efficiently (alternatively: UILabel + EAGLView = chaotic framerates), and use localized text allowing me to reach more people in the world.

No new game is complete without Apple's new Game Center service, so I learned the ins and outs of it. Blitz Blok Beatz will have a few to keep the goal-oriented players rocking out to their music for a while.

I've also made plans to upgrade Blitz Blok using all of these new improvements. It'll add in Game Center support, localization, some new graphics, better gameplay mechanics, more optimized code, and the new game state and menu systems that have all the bells and whistles of Blitz Blok Beatz on your iPhone or iPod Touch!

I haven't figured out how to market my apps on my own, so I'll need some help on getting the word out. There's an advertising service by this guy named Ed Turner I'd like to try out. If I can afford him ($44 a month over 12 months), then I'll give him a shot!

With all these new improvements, I can apply to a few other projects that I have been designing for over two years now... Maybe now I'm finally ready to put them into production!

The Sprite Module is Finished

The sprite module is finally finished, and I think it turned out well! The programmer can load up a single sprite sheet into a sprite batch class, and use the sprite batch class to instantiate a group of sprites to draw from that single texture.

Only one texture can be used for this class, but I may support a texture list per sprite if I can find a way to use it wisely... Maybe impose a 2-texture limit. I can still batch draw sprites, but I would have to use more draw calls to active multiple textures at once... Theoretically, I could very well draw an entire scene complete with the player, enemies, and props with a single texture batch object in a single draw call! This would be a good idea since I can retain the optimal performance I am currently getting by only using 1 texture if it is possible.

Another great idea would be to setup a quad map algorithm that divides static sprites up into a quadtree. Calculating the quadtree is slow, but it will make games that use this sprite lib extensively for 2D games render quickly by culling geometry.

Due to the way that SpriteBatch is designed to work and store its data, the quadmap would have to be its own class. What I would do is have my QuadMap class have a constructor that would take a list of SpriteBatch objects. All of that geometry would get consolidated into one giant structure, and sorted out spatially. Again, loading will be slow, so I would also add a function that would output the QuadMap's data into a serialized output file. Then, there would be another constructor that could load a QuadMap's data from a serialized binary file instead of from a group of pre-built SpriteBatch list. I think this would work just fine.

Before I do this, I'll have to finish a bunch of other stuff first such as cleaning up my Octree class, and getting it to process textures. I do not have the most confidence in this particular class. Another objective is to rewrite a new X file loader since the current one does has its limitations, and will cause crashes if the text is not in the correct format!

Sprite Lib Nearly Finished...

For the longest time, I have not had any formal 2D support for my game. I did not have a good system designed to minimize draw calls and vertex bandwidth until I took a second look at XNA. The XNA framework handles sprites by accomplishing my objectives, and this is how it works:

it batches sprites together.

There are some problems with this, however... The XNA sprite batch works in sort of an immediate mode where you must allocate your sprite data per draw group. The programmer signals when to start and stop allocating with the sprite batch's Begin() and End() methods...

Nevertheless, I took this same approach, and I think it will be a success! I do not follow XNA's example too closely, and in fact, I mix things up quite a bit! What I did was bring back the old sprite class I used to have back when I worked on the PSP, only this time, instead of having a texture reference, each sprite has a reference to a sprite batch class...

Here's how it works:

1) SpriteBatch Class:

• Loads the texture the sprite batch will use
• Creates/Deletes sprite instances
• Stores all vertex data per sprite instance into a single STL vector
• Stores a separate index lookup STL vector that works in parallel with the vertex list
• Does all drawing in one function call

2) Sprite Class:

• Holds data for a single sprite definition
• Is created/deleted from its parent sprite batch
• Does not directly store vertex data
• Does not directly have access to vertex data
• Has a matching index number to the vertex data in the parenting sprite batch

I have some of the functionality there, and I'm close to having the whole sprite class running. When it is finished, I'll setup a simple demo of it working, and post a video.

A Likely Alliance

I have been doing some work with my own developer-oriented social network lately. What good is it to have a powerful engine packed full with features when there is no production team? How about marketing? Is it possible to design the game, produce the game, and market it all by yourself? Unlikely these days...

So, I have been out for experience with working on projects with other individuals, and forming contacts along the way. Obviously, GameDev.Net is the perfect place to start! The developers there range anywhere from newcomers to the industrial to seasoned veteran developers that have been building games as a profession for years.

My area of interest in the GameDev.Net have been the "Help Wanted" forums lately. This would be a great place to get involved in projects in three different ways:

1) You can start a thread offering services to other projects either commercially or for free

2) Browse the forum for threads with people looking for help on existing projects

3) Post your own thread asking for help on your very own project if you have one

Everything isn't always sunshine and daisies on the GameDev.Net forums, however. Artists, whether they be sprite artists or 3D modelers, are in high demand all the time, and they usually don't work for free. Getting off task is always easy to do as well. Anyway, my social networking experience is pretty fun so far! I've met some pretty talented people, and I'm looking forward to building some great products with them.

A Ton of Work Finished...

My Catalyst Engine is coming along nicely! I do have a couple of screenshots too:

This screenshot is a demo of my level editor I designed. It allows the user to import content such as models, sound effects, lights, scripts, etc into the scene, and export the data out into a level configuration file file. This allows the user to perform to create some highly interactive level.

This screenshot shows off my support for skyboxes and particle emitters. The particle emitter system is very powerful and lightweight. I have not added support for stock shaders built into the lib yet like I have for my skybox.

Overall, this engine is rich with features, but it is still very young. There a plenty of other features I would like to add into this engine to further Catalyze my game development endeavors even more! One such feature is 2D sprite support. For now, users must add in their own sprite support, but now I have designed and am currently implementing a simple and efficient sprite module.

A Very Long Time

Well, this blog has been up for about a year now, and I have made a couple of posts on it displaying my progress. I took about a 2-month break from programming, and all game-related things, but now I am back. I have been working on my code the last couple of weeks, and learned a few new things too!

I have gotten my octree rendering system to work, but the collision detection system is still in the works. I have drawn up some diagrams to help me figure out how to manage my resources for our game, and it has brought up the question on how exactly to handle the scripting system...

The scripting system I am working on is pretty neat. I made a simple cut-scene of my soldier model I have been experimenting on playing its death animation in slow motion while the camera zooms around in a cut-scene. This was built back in October with older engine code though. I will update it when I have the time, and then go as to enable user input after the cut-scene to allow the player to move the camera around in 3D space and observe the scene later on.

I have gotten a bunch of other things done in the design end for our game, Forsaken Realm. I have been solidifying the plot, working on gameplay mechanics, and working on concepts for item/equipment generation. The plot has gotten a lot more interesting, and it has gotten longer.

Over my winter break from college, I have done a little bit of research on OpenGL ES 2.0. It is heavily shader-oriented, and I have been trying to stay away from them since I believed it would be an overwhelming process to learn how to use them. In the long-run, I decided to start learning OpenGL ES 2.0, and I have got to tell you, shaders make life much easier. I thought at first a couple years ago when I did not understand the basics of any 3D rendering pipelines, that it would be hard to write shaders, and I was right --at least at the time I was.

However, I have been pretty comfortable with how the rendering pipeline for DirectX and OpenGL for about 3 years now. I'm not saying I am an expert, but I understand more than the novice, and I understand many intermediate aspects of 3D rendering pipelines. If there is anything I specialize in, it would probably not be using blending equations and lighting, but instead, matrix and vertex transformations.

Anyway, I have decided to change around my model loading and rendering code substantially (and for the better) so that all my vertex skinning code would be executed within the vertex shader. This has actually made handling vertex data a long easier, and cut my code down by about 600 lines or so. I hope to support vertex lighting, normal (bump) mapping, reflections, etc... The question of whether I can support all of this or not will be a matter of time.

I hope to post some interesting content later on to show some realization of my work from these past couple of months.