iPhone OpenGL Developin’

I got a good session in last night, doing some plumbing code for OpenGL games. My need for OpenGL is modest here. Basically I just want to be able to use it as a 2D API to render rectangular areas with images.

So I came up with a few simple objects to help me: VertexSquare, ColorSquare, TextureSquare.  These encapsulate an array of values that need to be used in order to render a simple rectangle.  These give me, respectively, the vertices, colors, and texture coordinates of the rectangle.

I have already set up a matrix to pretend that the upper left of the screen is (0,0) and the lower right is (40,25).  This way I can use a grid of VertexSquares (actually, there is an object called VertexGrid for this purpose), and I can split up a texture into a bunch of TextureSquares (called a TextureGrid) in order to make a tileset.

I also encapsulate a VertexSquare, a ColorSquare, and a TextureSquare, in conjunction with a Texture object (that actually wraps a real texture) into something called a RenderSquare.

A lot of this exercise is to give myself those classes that I know will be useful in hammering out games.  Pretty much any language and platform I’m on needs a set of things like these in order to make work go faster. I don’t want to have to put together texture coordinates and vertices and color arrays. I want to have an object to point to and say: use this texture, this part of the texture, this color, and at these coordinates, and render.

I’m also getting re-used to the retain/release memory management stuff in Objective-C. I stuff a series of TextureSquares into an NSMutableArray in order to create a TextureGrid.  I always make mistakes initially until I’m reused to these things.


Design Awry

I was going along, working on a iPhone port of HamQuest, when I wandered into the same goofy chain of dependencies that I ran into the first time.  This time, I hope I have done better, but you can be the judge.

Player specific information(equipment, statistics, etc) is stored in a class called, appropriately, Player.

The representation of the Player on the map is a MapCreature, as are all other types of creature.

MapCreature has some creature instance information(wounds, mostly).

The Player class knows about the MapCreature instance for the player.

The MapCreature instance has a reference to a CreatureDescriptorBase, for which there exists a special PlayerCreatureDescriptor as a subclass.  For normal creatures, CreatureDescriptors are used (another subclass of CreatureDescriptorBase).

All of the various CreatureDescriptor instances and the PlayerCreatureDescriptor exist in a CreatureTable, which is used to populate a maze.

The PlayerCreatureDescriptor knows about the Player, so it can query it for statistics important to the operation of a MapCreature (mainly attacking and defending).

So, unfortunately, there is a circle: Player->MapCreature->PlayerCreatureDescriptor->Player.  I get around having an actual circular dependency by using a base class.

It is improved from the last time, however.  MapCreature only held a CreatureIdentifier, which would then be used to look up the CreatureDescriptor in the CreatureTable.  I realized today that it was silly, because then a MapCreature needed a reference to the CreatureTable.  So, cut out the middle man.

Thanks for listening.


Reese’s Peanut Butter Cup All Over Again

So, while I have been writing my first few “simple” games while learning objective-C and iphone development, I have to say that I need to modify my original plan slightly.

At first, I considered making a slew of small puzzle-type games and putting them out there for 99 cents, and build my iphone empire a dollar at a time.

I will still wind up doing some of that, to be sure, but I took a long, hard look at the app store.  Puzzle games have 9 pages of stuff.  Anything on the first page gets 100 sales a day.  Anything not on the first page is lucky to get 10-15.

So, the main strategy is be on the first page of whatever category your game is in.  A secondary strategy is to put a game in a category with as few pages as possible.

It just so happens that I was 90% complete with a game that fits well into the “Role Playing” category, and it just so happens that in the app store there isn’t even a full page of role playing games, and almost all of them are simple dice-rolling utilities.

So, part of the new plan is to port HamQuest to the iPhone (along the way, I get to fix a number of the architectural mistakes I made first time through), which I should be able to rip through in relatively short order.

The rest of the plan is the same. Pump out lots of stuff and have it up there cheap.  I’m hoping that folks buy more stuff from a developer that they like, so a few “good” offerings will mean sales of less complex games.

Who knows, though?


A Few Updates

A few updates today.

One. it is the first day (that I am aware of) in which an application with cheesy ascii graphics have appeared on the iPodTouch.
Which brings us to: Two, iPodTouch JetLag (a.k.a. JetLag 2008) is making good progress, and will basically be a clone of JetLag 2003 (minus one or two lucky charms).

Three. The controls for JL2k8 shall be the accelerometer to change direction, and touches will use bombs.  I have the direction part working.  I still need to implement lucky charms.