Developer's Journal

Apple Stealing My Idea? • 12/23/2007

Since my last post I have been working on creating a lot of new custom "types" for the Lua scripting engine. Mostly just the basics… simple structures to represent rectangles, sizes, points, colors, etc. I also created a new Tile class that is used to represent any visual object in the game window. I haven't completely solved the problem of building a complete game UI yet, but this approach will offer a lot more flexibility than the previous game board interface that only supported game tokens placed into squares in a grid. Cocoa programmers will probably quickly notice the similarity between Tiles and Core Animation layers (CALayers). :)

When I started up Xcode tonight I noticed that there were documentation updates available for download (one of the nice new features of Xcode 3). I started the download and then went to the Apple Developer site to check out the recent updates to see what was new and stumbled across a some new sample code for "GeekGameBoard".

If you read the brief descript for this sample program it sounds an awful lot like what I am trying to build with Tylez — well… except that they aren't trying to build a platform for others to build their own games, support scripting, or support multiple players. I downloaded the sample to check it out and was pretty unimpressed. It is very basic. Oh well, Apple might not have helped much, but Tylez is still in business. LOL

Building a Game UI • 12/20/2007

The holidays have me a bit distracted, but I am still making (slow) progress…

After getting the first two basic games up and running I started to consider what the best "next step" should be. There are three general directions that I am considering:

  1. At some point I know that I am going to need some kind of game launcher that allows the user to decide what game they want to play (assuming that more than one game script is installed). Also, at some point users will be able to save games in progress (if the game script supports it), and I need to have a way that users can see saved games. Both of these features could be implemented within the application menu (e.g. Game->New Game->Game #1 / Game #2… and Game->Saved Games->SaveGame1 / SaveGame2…), but that wouldn't lead to a very satisfying experience.
  2. I have also been thinking about how multiplayer support might work and what the experience of seeing who is online and inviting them to play a game might look like. There is some obvious overlap with the game launcher here — in order to invite another player to play a game you have to select the game. That makes me think that I really need to combine the game launching experience with this multiplayer "matchmaking" experience (unless the "matchmaking" only happens on a Web page… hmmm…).
  3. The basic game UI control that I have right now, a game board grid with controllable tile colors and game tokens chosen from a palette of about a dozen color sets, is enough for the basic games that I have been building so far and would probably work for a few others (checkers anyone?), but lots of games are going to need to build more advanced UI. Allowing the game board and tokens to be represented with images provides a lot of flexibility, but many games need to also show additional information like game scores, etc. I need to figure out how game scripts will be able to add these kinds of game UI elements.

Between these three directions, the last one seems like the most important to solve now. The game launcher and matchmaking experience can be thrown together with a cheap UI for now if I need to, but the game UI will restrict the set of games that can be built quite a bit and I don't like that restriction. In addition, depending on how flexible the game UI solution becomes, I might be able to leverage this work to build the UI for some of the other features.

Two Games Written in Lua • 12/08/2007

I expected to write a couple of posts talking about the my experiences with integrating the Lua runtime engine into the Tylez project. As it turns out, however, I had Lua compiling as part of my main project within an hour or so and was executing my first basic script (a typical "Hello, World!" starter script) shortly afterwards.

Over the past week I have spent some time doing some "refresher" reading on Lua (it's amazing how quickly I forget about the details of stuff that I have read if I don't spend a lot of time using it in real projects) - just a quick rescan through some of the core concepts and reading through the Lua API again. I started writing a C++ wrapper class for the Lua API, then found that I didn't like my approach and threw it away and started building another wrapper. Before long, I had thrown that one away as well and just start using the Lua API itself (the interface is actually pretty clean).

I started porting my first game, Flip, into a Lua script, adding each game engine event call and game platform call as they were needed. Within about six hours I had the basic game up and running again, as well as about 80% of the game platform interface. I spent a few more hours doing some fine-tuning and making the script simpler (the straight-forward translation from Objective-C to Lua isn't always the best way to write the script). Last night, I called the game "done"!

As an experiment, I decided to start creating a second game - one where I hadn't already spent a lot of time tweaking the implementation. Since I still expect to make a lot of changes to the game platform at this point, I wanted to stick to simple games. I made a clone of Connect Four, an old board-game by Milton Bradley. I had the basic game working in about half an hour (allowing two players to alternately take turns, no detection of a "win"). This morning I spent a couple of hours fleshing out the game details (game win detection, some additional superfluous animations, etc.) and I have to say that it turned out great!

So, in the course of a week I have integrated the Lua runtime engine into Tylez, ported my first game to Lua script, and built a second game from scratch. In the process, I have run across a few enhancements that I want to make to the basic game platform, but all-in-all this felt like great progress!

A New Rendering Engine • 11/30/2007

It took several days, but I have finally finished getting the engine up and running with a Core Animation-based rendering system. I actually had my sample game, Flip, working under Core Animation with a single layer that just contained the entire old game board a few days ago. That approach doesn't allow me to take advantage of any of CA's capabilities though, so I continued with the transformation by moving every game token to its own layer.

At this time the game board is still a single layer and I haven't broken out individual tiles into separate layers. I might change this down the road, but for now I just wanted to get the game up and running.

I haven't really done much to push the animation possibilities of CA yet, but tokens now fade in and out and fly around the game board when they are moved. Since Flip doesn't really move any game tokens, I added a new feature to the game engine to "shuffle" the board. This feature randomly generates a new game board and then randomly moves/destroys/creates tokens from the current game board to form the new one. Over time, I am sure that I will start leveraging more and more of CA's power.

The First Game is Working! • 11/20/2007

After finishing a lot of initial graphics to build the icon last week, I spent most of this week cleaning up the code (especially the token-drawing code) to make things simpler. As part of this effort, I also wanted to get some of the basic mouse and keyboard event handling hooked up. In order to test the event handling, I needed the UI to respond to each event in some way, so I started adding some very basic UI responses (such as toggling the color of a token when it is clicked). After I got this working, I realized that what I had was actually pretty close to a very simple game… so I spent some time and finished it!

The game is very basic. I start with a square game board (3x3, 4x4, or 5x5) and place a token on every tile, randomly picking one of two token colors (red or aqua, in my test). Then the user clicks on a token, the color of the token that is clicked is flipped… as well as the color of every adjoining token (but not diagonals). The goal is to get the board to a state where every token is the same color, at which point the board flashes and resets to a new random state.

This is a very simple puzzle game, and honestly not very interesting or challenging. It provided a great way to test my basic event handling (I also added code to change the highlight color for every tile that would be affected by a click, based on the mouse position, and allowed the numeric keypad to work as if the user clicked on the 3x3 game board).

What I have now is a complete, working (yet lame) game that is implemented as part of the game board view. Architecturally, this approach won't work well when I need to add the ability to write games in a scripting language, though, so it looks like I have another week of "cleanup" work ahead. (sigh)

An Icon is Born • 11/14/2007

I am so tired of seeing the standard, generic application icon that Mac OS X uses for every new project. It's funny how a project just seems more "real" once the application has a real icon. Well, as of today Tylez finally has an icon of its own.

I'm know that I am not an artist, no matter how hard I try. Icons, in particular, have always seemed very hard to generate. Maybe if I was more proficient at using one of the 3D graphics applications that so many icon designers use nowadays… Anyway, I have been playing around with a lot of different graphic concepts for my first Tylez game board and stumbled across a few graphics elements that I thought would make a pretty good icon if put together in the right way.

The idea seemed simple… modify some of my code to draw things a little differently and then just run the application and take a screen shot. As it turns out, I ended up spending over six hours tweaking the graphics so that things would look just the way I wanted. Every time I looked at the image I would see something else that I could improve. If this was just the game UI then I would just move on for now and come back to the finishing touches later on, but this is my icon!!! It must be perfect!

Now time for the screen captures. That turned out to be a challenge, too. My graphics use a lot of transparency, and capturing the running application loses all of the subtle transparent nuances that I liked (unless there is some magic application UI- capturing trick that I haven't discovered yet). After a couple more hours of reading and coding I was able to hack together a solution that would render the application UI to a bitmap image and save it as a PNG file. It's amazing how much you can do with very little code on the Mac. :)

I captured the application UI running at several different resolutions (so that the icon would scale smoothly) and finally have the finished result. This icon will provide readers with a first glimpse of the Tylez graphics as well. (Well, OK, this is just one of several different graphics directions that I might take — we'll have to wait and see what the finished alpha release looks like.)

Leopard is Here! • 10/30/2007

Mac OS X 10.5 (Leopard) shipped this week and I installed it right away. There are several new development technologies in Leopard that I have been interested in trying out, but I never had access to the beta releases (with Apple, unlike Microsoft, you have to pay for that privilege).

Objective-C 2.0 adds some nice features though I am not sure if I will actually take the plunge and turn garbage-collection on or not. I have spent most of my career programming in C and C++ and have never really had any problems with memory management. Maybe I will change my mind later on… time will tell.

Core Animation (CA) is the technology that I was really interested in trying out. I have already taken a couple of days and written a couple of test animations using Core Animation. Overall, CA is pretty slick, but I have already run into a few quirks (bugs?) that will need to be avoided. I was surprised at how quickly I could get a bunch of visual elements flying and animating around the screen with impressive performance (on my Mac Book Pro, anyway… I haven't tried running my test applications on older hardware).

I strongly suspect that I will be leveraging this new technology in Tylez, which means that Tylez will require Leopard (or higher) in order to run. I am not too worried about this limitation because I suspect that it will be quite a while before any real version of Tylez is shipping.

Scripting is Fun • 10/16/2007

One of the key components of Tylez will be its scripting engine. The scripting engine is what provides support for programming your own games using an "easy" programming language. There are a lot of candidate scripting languages floating around out there. I have a little bit of familiarity with most of them (Perl, PHP, Python, Ruby, JavaScript, AppleScript, Lua, etc.). Each of these languages (many of which look so similar to one another that they might more accurately be referred to as "dialects") comes with their own set of pros and cons.

After looking into all of these options (as well as a few others), I have decided to use Lua as the scripting language for Tylez. The Lua engine is extremely fast and lightweight and is designed from the ground-up to extend applications with scripting support. Some recent notable examples of applications that make heavy use of Lua include Blizzard's World of Warcraft and Adobe Photoshop Lightroom.

Tylez: Game Design Made Easy • 10/02/2007

I have been a software developer for many years and have always been interested in designing and building my own game, but never seemed to have the time to get started. Looking at the successful games that are on the market now, the idea of building my own game seems pretty intimidating. I can draw (a little), but I'm not an expert in 3D modeling, texturing, and character animation. I dabble around with music, but lack the talent to compose a rich cinematic soundtrack - even most of the sound effects in games can be difficult to produce.

I did some research into some of the game development engines that are available on Mac OS X (my platform of choice). The two game platforms that looked the most promising were Unity and Torque. I don't know about you, but some of the more advanced math behind 3D engines just makes my head hurt. Designing my own 3D content to use in the game is a challenge as well. Torque Game Builder focuses on 2D game development (more my speed), but even with TGB it still takes a ton of work to build a new game. I also found the development environment for TGB to be a little… um… well, they have a free demo that you can download to try it out for yourself.

In particular, there is a class of games that none of the existing game engines address very well — board games. Board games are generally much easier to design than other games because the number of possible moves and game "positions" is pretty limited in comparison. I started thinking about what work would be involved in building my own game engine for board games. The more that I thought about it, the more excited I became… I may not be a 3D modeling matrix-multiplying musician, but I can DO this!

I immediately started making lists of all of the features that could be added to a basic board game engine along with lists of all of the games that could be built with each feature. The list started getting pretty long. The project started looking like it would take years to build. Ok… time to start taking features back off of the list.

At this point I think that I have a very basic list of features that will allow me to get a basic version of the game engine off the ground so that I can start playing with it and figure out what features are really the most important to add. The good news is that there are enough feature ideas to keep improvements coming for a long time. :)

Time to get to work…