Recently I took the plunge and dove whole-heartedly into the complex world of 3-D. My only foray into 3-D Programming was with an unreleased Graphing Tool which also allowed for the use of Direct3D to create 3-D graphs. I’m tempted to fire that project up now but I know if I do I’ll be working out unresolved references to files that have moved or been deleted in the intervening 9 years since I last dealt with it. That project used Visual Basic 6 and the DirectX7 Type Libraries.

In this particular case I ended up deciding on using C# and OpenTK. After some effort creating the initial setup, and even struggling to get blocks to render, I then introduced a Physics engine, in this case, I decided on Jitter Physics. I’m still learning and there has been a good mix of trial and error and “OK, let’s think this through on paper”.

As it is now I have limited camera control, and a single block that doesn’t have any subclasses.  I’ve been fiddling with the OO design to try to get something that tries to predict what I’ll need, which is a tricky business considering I’m not very versed with 3-D programming.

That has been the stumbling block. Primarily I’ve had difficulty extending my programming into the third dimension.  I have a solid understanding of many of the principles behind 3-D, but this basic understanding lacks even a rudimentary understanding of the significance of Projection and View Matrices. I hope to get a better understanding of this as I work on this new Project.

As for what this new project is going to be- That’s an interesting discussion topic as well. Originally, I was considering some boring 3-D version of BASeBlock. However, after adding in the physics engine, I got to thinking about how I could use that as part of the core game mechanic. The best I could think of that would provide an interesting Gameplay experience while being reasonably easy to implement was a 3-D implementation of a game like “Spring Up Harmony”.

In such a case, the game would not really consist of a ball and paddle style of gameplay, but, like the aforementioned game, would instead be oriented around the player shooting balls at the blocks in the level. In “Spring Up! Harmony” the colour of the ball would determine what objects it could effect. Instead of a paddle, the game would have a “catching” bucket type of element, where you attempt to catch blocks and balls as they fall before they leave the game field. While there are some considerations to work through particularly with the implementation of the game in the third dimension, and I would like to of course add my own personal touch, but I think such a gameplay goal is completely within my reach.

Another nice thing about a new project is I can redouble my efforts- refactor earlier rather than later. I’ve already laid out a framework for HUD display as well as myriad blocks or other in-game objects. With BASeBlock the biggest thing I wish had been different from the get-go would be the handling of different game states. Currently it is essentially a giant switch() because it was written before I was aware of the methdo which uses an interface and allows seamless addition of new states as well as switching between them without losing the information from a previous state.