When the uDevGames 2002 Contest was announced I told myself that I didn’t have time to write a full game in three months, but a voice in my head kept telling me to try. After three days of internal debate I caved in and began to work on Black Cube. My goals were to develop it using only inexpensive or free tools, to learn OpenGL, and to deliver a completely finished game by the deadline (I didn’t want players to think, “That was a fun demo, it’ll be really nice once he finishes it.”). Also, the knowledge that I would never have to work on it again after three months was a powerful incentive to keep pounding away at it. I kept telling myself, “Just think, once you finish this you can go back to playing Warcraft III…”
What Went Right
blackcube03.gif
Clear Goals and Scope Control
I only had three months to write a game from scratch, and in my spare time. Given that my last game took me six years (off and on) to complete, clearly some changes in my work habits would be needed. On the plus side, I have many years of professional software development to draw on now. On the minus side, I now have a family and a demanding job, and not a whole lot of spare time—I needed a plan.
Given that time was not on my side, the number one factor to my success in finishing Black Cube before the deadline was scope control. I have many game ideas (don’t we all?), but fortunately one of them was this puzzle game. The graphics were simple enough that I expected good performance on any machine capable of running OpenGL and Mac OS X, so very little time would be needed for performance tuning. Likewise, the sounds could be quite simple provided they were appealing enough. Granted, I did not know OpenGL yet, and hadn’t yet used Apple’s development tools, but this game seemed like a good project to learn those on.
During the actual programming of Black Cube, I kept my eyes firmly on my goal of delivering a complete game. This helped me cut the right features as the deadline approached. For example, I originally imagined a background story to the game, involving a stellar cartography mission. Mapping the pockets of “dark matter” would allow ships to pass safely through the area of space represented by the board. But as time grew short I concentrated solely on the puzzle element, because without that I had nothing. I can’t say enough how important clear goals and scope control were to this effort. Whenever things went wrong I reviewed the ultimate goals of the project and adjusted my plans.
blackcube04.gif
The 3D Rules
Deriving the new rules was interesting. An important principle of the original 2D game was reversibility: if you fired a ray in reverse, it would travel the same path as the original ray, but backwards. Most of the 3D rules can be derived from the 2D rules and this principle. The hardest rule to come up with was the 3D corner rule, and even after I had the flash of inspiration that the ray should split in two, I didn’t quite believe that it solved the problem (thankfully my friend John McIntosh understood the rule immediately and convinced me that it worked!)
My biggest fear until the game was finally completed was that the new rules would be too complicated to be fun. Each player has to decide that for themselves, but I enjoy playing the game and I’ve heard from some other players that they like it as well. The rules are rich enough to yield some interesting bounces that are difficult to interpret.
iDevGames
Aside from creating the uDevGames contest, iDevGames offers many useful resources for Mac game developers. In particular, all of Black Cube’s sounds were provided by iDevGames, as was most of the code I used to load and play sounds. Two weeks before the contest deadline Black Cube had no sound, and only a week before the deadline it did.
Good Tester
One asset that I had less control over was the quality of the feedback from people testing the game. Fortunately the friend who had helped me figure out some of the rules for Black Cube took a shine to it and played it a lot. He sent me several pages of useful feedback. He even figured that the deflection rules allow the ray to bounce around the board infinitely! To my knowledge this has never been seen in an actual game, but thanks to his warning I made sure the code handles it gracefully (basically, a ray is “absorbed” if it travels for too long). I also got some useful comments from people who didn’t play the game as much, and it all helped the final game immensely.
blackcube05.gif
Game screen
What Went Wrong
Time Constraints
As strange as it sounds, the lack of time I had each day to work on Black Cube wasn’t always a bad thing. Rather than jumping in and coding each day, I was forced to think about what I was going to do. During my driving commute to work each day I would mentally design changes to the code, and sometimes I’d realize that my first approach wasn’t going to work even before I’d written anything.
However, the short deadline did force me to cut certain features out. Some examples: the game is not localized for languages other than English, and is not designed to make localization easy. It relies heavily on color and may be unplayable by color-blind people. High scores are not saved. And last but not least, I had to drop plans for a Mac Classic version early on.
Perhaps the worst problem with the game as it currently stands is that it is a CPU hog. One of the reasons is that it polls for events (using the function WaitNextEvent) rather than using Carbon Events. If this were a full-screen game perhaps no one would have noticed, but early in the project I converted it into a windowed app for various reasons. I did get a couple of complaints from players about CPU usage and I may address it in a future update.
Limited Artistic Talent
My artistic skills are limited, and so are my tools. To model the game arrows I used graph paper and typed polygon coordinates into the code by hand. This was adequate for a puzzle game with simple screen elements, but in the future I’m going to have to invest some time and possibly money in order to make the game art more interesting.
My other artistic failure was Black Cube’s icon. It wasn’t incredibly bad, but it looked like it was drawn by an amateur. Fortunately a passing graphic designer named Jesse Holden took pity on me. After playing the first release of Black Cube he asked me if he could make me a better icon. I really like what he made and feel that it helps makes a good first impression when someone is about to play my game for the first time.
blackcube06.gif
Design concept
Looking forward, it is clear to me that the kinds of games I write in the future will be limited unless I start to involve someone else to help with the art assets. That’s a big decision for me to make because I get a lot of flexibility by working alone. If I don’t like how a game is turning out, for instance, I can make big changes without consulting anybody. Conversely, when my professional job becomes especially stressful I sometimes have to cut back on my programming hobby.
Reliance on Third-Party Code
I relied on sample code to get two parts of the game up and running quickly: Apple’s OpenGL setup code, and iDevGames’s “Core Audio Test” example for my sound code. In both cases there were problems introduced by the sample code that I almost didn’t have time to resolve. For the OpenGL code, Apple’s full-screen example does not allocate a sufficient depth buffer for most 3D applications. I spent over a week trying to figure that one out before I finally got help from someone on Apple’s OpenGL mailing list.
The problems in the sound code were easily fixed, but since I added sound last I would not have had time to fix any significant problems. It also meant that much of the beta testing did not test the sound code. That was an unnecessary risk, but I did have the fallback plan of releasing Black Cube without any sound.
Lesson learned: leave adequate time to incorporate third-party frameworks and code, and put them in the code early so that they get the same amount of testing as the rest of the game.
Final Thoughts
I am very pleased with Black Cube. Although it is not a game that appeals to everyone (“not twitchy enough” was a comment I heard), the people who like it seem to like it a lot. And of course it feels good to have written a game again, after so many years. I am indebted to Carlos Camacho and iDevGames for the incentive and helpful resources that pushed me to develop this game.
- Genre: Puzzle
- Developer: Matt Diamond
- Url: http://www.mindthecube.com/Black_Cube.html
- Team size: 1
- Released date: November 12, 2002
- Project length: 3 months
- Development hardware: PowerMac G4 400MHz
- Critical applications: Apple ProjectBuilder (v.2.0, April 2002 beta), Spark ME by TC WORKS, Pencil and graph paper
puzzle,OpenGL,3D,Carbon,ProjectBuilder