Jeff Fal's Development Blog

It’s been a month-and-a-half since the last update, and Dungeonism has progressed by leaps and bounds. I’ve kept tightening the graphics, and I’m getting close to having the whole look nailed down with all the tiny details ironed out. Nailing and ironing, that’s what I’ve been doing. I’ve added new mechanics too, and as I finish up the graphic design, I’m going to focus on creating more and more new mechanics.

However, the most useful thing to you, dear reader, is that I made a video demonstrating the game.

It’s past time for an update on Dungeonism. It’s very far along. All summer and even still, I’ve been focused on presentation aspects, so the core gameplay has changed too much since May. On the other hand, it looks much different now, and hopefully all the changes are for the better. I’ve kept the basic shapes consistent for all the monsters, but I’ve changed their fills from solid colors to subtle gradients. I’m also creating different poses for them whereas before, only the color of their outlines would change when they were doing different things like attacking, taking damage, and resting up. I’ve added background patterns to the game, so now instead of plain black, the game takes place over a texture that’s determined by the level type. I’ve also spruced up the look of the walls. Anyway, all of this is best illustrated with illustrations. Screenshots, that is.

Cocos2D for iPhone sadly does not have a class for a button that lets you customize it with different text, text color, and background color. After some research, I decided the easiest way to do this on my own would be to create a button from a blank sprite, set a color for that sprite, and attach the text to that sprite. So I created a class that did just that. This weekend, I upgraded the class a bit to support a border and simple drop-shadow (really just a slightly displaced block of color). It’s still acting a little weird, but I put some hours into it, so I’ll post the code here for those who may want to see what I did.

Working on the interface for buying and selling items in Dungeonism, I needed a menu that was arranged as a grid. There seem to be some choices out there for this, but I couldn’t get anything to drop simply into my project. Instead, I came up with my own solution, which is a clunky, but at least it’s simple.

I’ve been using the CCMenuAdvanced cocos2d extension to my single-column scrolling menus, so I made a CCNode subclass to which you can attach several menus. In its draw function, it checks to see if any of the menus have moved up or down, and if it finds any, it moves all menus in the same way. The code for the class is below.

Lots is done with Dungeonism! In fact, I’m packaging it up for playtesting and preparing to do some more work on the graphics, as the gameplay is getting pretty close to done. A huge task for finishing the gameplay has been making all the monsters I want in the game, so to celebrate completing that, here’s an image of all the jerks that try to kill you in the game.

When I started coding in Objective-C, one of the first things I learned about was properties. The tutorials I worked from showed me properties before talking about instance variables. In fact, they didn’t go into much detail about instance variables, so you’ll forgive me for starting out thinking that properties were instance variables.

It wasn’t even a problem until I made a sub-class that needed to use one of its super-class’s properties. It didn’t think the property existed. I thought maybe the problem was that the property was only synthesized in the super-class, so I tried copying the “@synthesize” line into the sub-class’s implementation. It seemed to work at first, but it turns out it was just creating a new property. It didn’t get or set the same data that the super-class was referring to.

Of course, what I was missing is that the whole point of properties is not to make a place to store data. You can do plenty of data storage with simple instance variables in the “@interface” block like so:

@interface Class : SuperClass
{
ObjectClass *myData;
}

You use properties when you want to give outside objects access to data, and all properties do is automatically create method to get and set instance variables. So I could write an object like this:

@interface Class : SuperClass
{
ObjectClass *_myData;
}

- (id)myData;
- (void)setMyData:(ObjectClass *)myData;

Or I could get the same result by writing this:

@interface Class : SuperClass
{
ObjectClass *myData;
}

@property myData;

Now when you write “@synthesize myData;” in your implementation file, you should think of that as the same as defining two methods, “myData” and “setMyData”. In fact, if you don’t write a “@synthesize” line and just start typing “- (void)setM”, Xcode will want to finish it as “- (void)setMyData” because declaring the property in the interface sets us up to expect getter and setter methods in the implementation. You can even leave “@synthesize” out of it and define the methods by hand, if you want. That can be convenient if you need extra stuff to happen when outside objects get and set your properties. Which leads me to another thing that confused me. When you define a property, you’ve also got options like this:

What’s the difference? The difference is what kind of setter method you’re automatically defining. “(assign)” gives you straight up assignment. “(readOnly)” doesn’t let you set at all. “(retain)” does the extra magic to manage the memory for your property. This is where properties get really nice. You can make sure your object is getting retained and released at all the right times if you use “(retain)”. And you can be sure that when you assign your property with a brand new object, the old one will be disposed of correctly. When you deallocate, you don’t release this kind of property. Instead, you just assign it to nil. Your synthesized setter method will do the rest.

The most daunting thing about learning Objective-C after living in the world of high level scripting languages is the memory management. From the beginning, I figured it would be a hassle, but I didn’t think it would be complicated. Turns out, it’s not even though there’s a lot written out there on the Web that makes it sound that way. The best article I’ve found is here: Objective-C Memory Management for Lazy People. Some simple rules make the whole project very easy.

If you own it, release it.

If you don’t own it, don’t release it.

Override dealloc in your classes to release the fields that you own.

Never call dealloc directly.

Which are made simpler by these rules about when you own something.

You own it if you alloc it.

You own it if you copy it.

You own it if you new it.

Easy. As soon as you write one of those three commands, ask yourself where you’re releasing the object in question. If you allocate something in your init method, you probably want to release it in your dealloc method. If you allocate it in a method and never use it again, you probably want to release it in the method. If you allocate it in one place and then need to pass it off somewhere else, you probably want to autorelease it, which is just like releasing except that it doesn’t happen right away. Autoreleasing is good for methods that return objects. Chances are that when your method returns an object, the object that called said method will have a way to retain the object on its own without your help. And if it doesn’t, it should. A lot of your convenience methods like NSArray’s arrayWithArray: provide you with autoreleased objects, which is nice. That’s why you don’t have to release them yourself.

Things get a bit more complicated when you throw properties into the mix, but I’ll leave that for another time.

Here are a bunch of diagrams of special rooms that will go in the dungeons of Dungeonism. The blocks represent — in order of appearance top left-to-bottom right — walls, breakable blocks, bad guys, movable blocks, bombs, pressure plates, coins, remotely-activated moving blocks, gates, holes, and switches.

My functioning Dungeonism app still exists in the world of placeholder graphics, but I have been working to home in on the design direction I want to take once the gameplay’s ready to go. To that end, I’ve got a small pool of concepts I’m playing with. My process is to every once in a while remove two concepts from consideration and come up with two new ones to replace them. Here are the outtakes so far:

Search

About Me

I'm Jeff Fal, and I'm an information architect and front-end developer working in Denver. I have been working on the Web since 1998 and am interested in learning at least a little about most Web technologies. I'm most experienced with HTML, CSS, JavaScript, and Flex. Soft Werewolf is my place to play.