Castle Conflict: Finished. We can resume sleeping.

It is 11:17 pm, make that 11:18 pm, on Wednesday night, April 15 2009.
In roughly 42 minutes, Josiah and myself are expected to have our game done, based on the deadline that we set for ourselves.

And we are able to stop here and say, we met our goal.

I mean sure, we could continue to sweat the minutae and make the game more and more polished. That is, in fact, what we have been doing since Sunday. This project went off surprisingly well. All of our key tasks, from the first priority (needs to be done for the game to be complete) to the final priority (Would be nice but far from essential) were finished, minus a couple that got scrapped.

In that time, we've taken a step back from the game and focussed on the user experience, and I think perhaps that was just as important, and that if we hadn't finished early and had that time, the game would not be considered a success. I mean - the gameplay itself is fine. But I think the two of us both learned a lot about making a product in this time, as well as about the work flow.

The exciting thing is that at the end of 8 days, the two of us have made a game together, complete with everything from audio to ai to kick butt graphics to an easter egg named Sir Theodore Quentin III.

The last is proof that the two of us get along well and are able to make each other laugh, and also a sign of our love for the game.

Perhaps I shall write an in-depth post mortem tomorrow. It might even be better to do so after the game has actually shipped, since by then I'll have actually got it on the iPhone (still haven't gotten my developer approval from apple) and will have more experience to share.

But in the mean-time, I will share some screenshots and small tidbits about them:



Our button, in the iPhone simulator.




New title screen, complete with sexy new logo.



What the player sees the first time they play the game.



The help screen, including the first tantalizing hint about our Easter Egg. Hint: He does not show up in the help screen initially.



Initially it looks like this.



When the player does well, the game politely prompts them, from the stats screen, to try a harder difficulty level. If they do really well, they get a trophy!


Biggest Problem

The biggest problem I encountered with cocos can be demonstrated with the following screenshot:



As can be observed, there are strange lines around the sprite. I observed this many times, often with scaling and occasionally with moving objects. My initial instinct was that it was a problem with the sprite sheet, but further investigation revealed this was not the case.

Research in the cocos2d for iPhone community revealed that this problem actually occurred because my units had floating point positions. Given that my game moves dynamically based on time, it was entirely unavoidable that this would be the case, but rendering at floating point positions created the behaviour seen above.

The solution was far from elegant but given our time frame, perhaps the most reasonable. (The elegant one would be figuring out why cocos2d or openGL was doing that and fix it.) Essentially, I removed as much scaling as I could, and then, in my units, taught them to move with two positions - one position that they knew about, with proper floating values, and another that cocos new about, which was their position rounded to ints.

Why were two positions necessary? Why didn't just ints work? I actually did try it, but it had some strange behaviour. Characters were jumping around choppily, and some characters weren't able to move because they didn't even travel a pixel a frame! In short, any unit whose speed was less than 60 pixels a second was unable to move properly, and only three units in the game move faster than that. As such, the internal floating point position was essential to keep the movement fluid and fun, while the render-only rounded position was essential for proper rendering.

And that is the end of the reign of Castle Conflict. With 21 minutes to spare before our deadline, I end this blog post.

A Title

According to our xp-dev page, we have completed 95 of 106 tasks. Of the 11 tasks remaining, they range from getting the sounds playing in the game to getting our splash screen in the game. We are in the final stretch.

The main things we are going to be working on from now on, other than the above mentioned essentials, are the 'shiny' things that will give the game more appeal - little animations here and there to make the game feel more alive. As well, because it has not yet been put on an iPhone (and won't be until I get approved by apple), I can't verify that there won't be some performance snags we haven't yet encountered - but those can and will be dealt with when appropriate.

Some of our recent progress:

Screenshots


The title screen. As you can see, it lines up directly with the main screen, such that when you click Play, it appears to the player as though the hud simply changes. We thought this was essential to give the player the feeling of being in the game from the get-go.

As the continue button suggests, saving and loading is functional. The game also auto-saves when it is closed.

There is one other milestone hinted at by this title screen: we have finally come up with a name for the game. We actually were fond of Castle Clash but it sounded too close to Castle Crashers. After much pondering over names, we finally settled close to where we started, with Castle Conflict. It's not going to change the world; but then again, it's just a name.


Some of the aforementioned sparkle is in this screenshot - a bird flying in the background, and sunlight reflecting off the water. Just tiny little things that aren't very obvious but help give the game a polished feel. (If you can't see them, try right clicking -> view image).


The settings screen, with the font built by Josiah on it. This one hints at a milestone above and beyond the settings that we hit today - artificial intelligence. The ai now uses all units and is far more intelligent than it was previously.



The new organisation of the buttons. Now they are sorted by functionality and price. Some extra tweaking will probably still go into this area of the game. (For example, no price is shown as of yet)

Feeling

Josiah and I are both feeling highly optimistic. I think the biggest thing about this game that makes me proud to be working on it is that every time I see it, I want to play it. The graphics are appealing, the gameplay smooth and pleasant. The experience feels very well thought out and accessible.

I actually can't wait to be done so I can put it on my iPhone and actually play it.

We have 4 days left after today to hit our deadline.

Newest Images

Current Progress:

Images speak louder than words - below are images of where the game (still untitled) currently is.




Taking the opponent by storm - Cavalry and zeppelins, in action.



A shot of the ground units in action - the woodcutters, armored knight, and foot soldier.



Bomber laying waste to whatever it can




Cannon launching a projectile against the opponent


Staying on Track?

Today was Friday, the third real day of work on the project. And at the end of the day, nearly all graphics were complete, and nearly all gameplay was complete. There are still a few areas that are going to need tweaking - the ai only knows how to use three of the units, for example, since I haven't touched it since the original prototype from last Sunday.

Main areas we have to investigate still include: interfaces (as you might be able to tell from the images, it could use a little tweaking in terms of layout), audio, and the general niceness that people expect with iPhone applications (auto-saving on quit. etc).

We are well on track to have all of this done by midnight next Wednesday. To our surprise, we may even be able to finish sooner, if we are able to maintain our pace from the past three days.

First day of madness

The secret to getting things done is just to do them. Over the course of today, Josiah was able to make most of the graphics for the game, and I was able to get almost all of his graphics in, get animations in, add a couple more units, and help prettify movement.

We started today with the following: . (Anyone who plays game maker games may recognise the art in this game as being ripped from a game known as Medieval Clash ... this was done during the prototyping stage to enable me, a programmer who can't draw, from having to try and draw things. The game we are making is in fact inspired by Medieval Clash.)

By the end of today, the game looked like this: .

This can be compared with Josiahs latest mockup, and you can see that we are well on track.

You may notice in the above image that there are two buttons repeated, and that they still have the old graphics. This is because I have not yet got Josiahs button images in the game (they are already complete). Cocos does not have an Atlassed HUD Image, like I thought they did, so I'm either going to have to get the HUD split into a separate image for each button state (bad ... ) or figure out another solution.

Now, I'm going to end this blog post on a quick tutorial on what specifically you need to create an animation in cocos2D and have it play and repeat. There may be a better way; this was the best I could find today. Due to our development cycle, the quick and easy wins are what we are aiming for.

Step 1: Create an AtlasSpriteManager

Assuming that you have an image named img.png, make the following call:

AtlasSpriteManager* mgr = [AtlasSpriteManager spriteManagerWithFile:@"img.png"];

Once you have your mgr, add it to your Layer, Scene, or other Cocos2D node.

[self addChild:mgr z:GAME_DEPTH];

Step 2: Create an AtlasSprite and add it to your AtlasSpriteManager

CGRect rect = CGRectMake(0, 0, 50, 50) ;
AtlasSprite* sprite = [[AtlasSprite alloc] initWithRect:rect spriteManager:mgr];
[mgr addChild:sprite z:GAME_DEPTH];

Step 3: Create an animation
An animation in Cocos2D is represented using an AtlasAnimation. So create an atlas animation and supply it with the rectangles you want.

AtlasAnimation* animation = [AtlasAnimation animationWithName:@"anim" delay: 0.1f];

If your sprite sheets, like many that exist, are laid our horizontally, you can use a nice cheat to get your sprites lined out without having to hard code each value.

int numFrames = 4;
for(int i = 0; i < numFrames; i++)
{
 int x = rect.origin.x + (i * rect.size.width);
 [animation addFrameWithRect:CGRectMake(x, rect.origin.y, rect.size.width, rect.size.height)];
}

Turn your animation into an action

Next, you must create an Animation action and apply it to your sprite.

id action = [Animate actionWithAnimation:animation];
[sprite runAction:acion];

On Repeating
The above will actually only play your animation once - if you want your sprite to play repetitively, you must create another action from your initial reaction that repeats. This can be done as below:

id repeatAction = [Repeat actionWithAction:action times:100];
[self runAction:repeatAction];

As best as I could tell, there was no way to create an action that would repeat forever. Supplying an aribritrarily large number to times may work in some cases, but I'd recommend actually digging deeper and finding a real solution, or implementing one, in most cases. In the case of this game, because of the small time frame and because our objects are not on screen for longer than 10 seconds at a time, setting the action to repeat 100 times was a suitable solution.

The week of no sleep

Based on how hard I consistently push myself, one might begin to wonder if I was perhaps a little bit insane.

Let's review the facts: I am developing three games at the moment: one full time (Gwabs), when on the side when I have the time (Population Control) and one is awaiting some feedback from our desired distributor before I have anything to do (NaviBlast).

So why is it, then, that I would think it would be perfectly okay to start a new game project? Using new technology I'm not familiar with?

And why would I set the goal of completing that game by midnight, next Wednesday?

The Plan

The game I am making is currently untitled. The reason that I feel that it can be completed is because of two very simple facts:

1) I was able to program the core gameplay / prototype in 7.5 hours on Sunday. Giving myself 8 days to polish it into a product does not seem unreasonable, as long as I am able to dedicate enough time to it.

2) I am working with Josiah, an old friend of mine, who I have worked on games with in the past. Him and I are both able to put in a fair amount of hours on this project to ensure that it succeeds as quickly as possible. Josiah is amazingly talented - he has been on several game projects, doing game design, level design, audio work, and pixel art. While every one of the games he's worked on was an indy game available for free, his work ethic is superb. Currently, his main project is a computer game called Worlds Beyond. Josiah also does music, and has his own band, Swimfail, under which he has released 3 LPs and 3 EPs.

The Pitfalls

Alright, so it sounds like we have a dedicated team. But that's not enough, and there are several pitfalls that need to be considered.

1) We have two people doing the job of 4. Josiah is doing all the art and audio; I am doing all programming and business side of things. At the same time, both of us have been involved in the game design process.

2) We have 8 days. But that doesn't mean that we each have 8 days to contribute. As previously mentioned, we are both actively involved in other projects. I have to give Gwabs precedence over this game, and will have to spend time on Population Control. Josiah probably has other commitments of his own.

3) Josiah does not have an iPhone. We are developing for the iPhone, but everything that we build, he is not going to be able to see. Only I am going to be able to see our final product, and he's going to have to rely on screenshots and screen captures to help him know what tweaks he needs to make.

4) Josiah lives in Victoria. I live in Calgary. In short - we are not even going to see each other in real life during the course of this project.'

5) It's on the iPhone. That means that the game is going to have to gracefully handle the player quitting at any time, incoming phone calls, etc.

The Method

So how are we going to overcome the above obstacles?

1) Rapid Design Process - almost as soon as we agreed to this project, Josiah and I spent about 3 hours fleshing out the design, figuring out how we want things to look / what we want to accomplish, and by the end of it, we had what was roughly a full on design, fleshed out as rough notes. Feature Lock has already been implemented.

2) Tiered Design - Our design allowed us to separate different gameplay elements into different categories of importance. If we don't have units that can collect resources, our game cannot work. If those units don't have an animation for harvesting resources, we can still make it clear to the player what's happening. Perhaps we don't need to include every unit; flying units, for example, add an extra layer of balancing that we may not need if time does not permit.

3) Constant Communication - We have to ensure that we are both up to date on what is going on. There can be no confusion about who is doing what, or when we can expect art assets.

The Tools

1) XP-Dev: XP-Dev is a free subversion host (up to 1000 MB) and also provides the ability to create and assign tasks, create wiki pages, report bugs, etc. We are using XP-Dev for our tasks, to sort them by priority, and estimate how much time the project is going to take.

2) Messenger - In order to remain in constant communication, we need to be able to communicate constantly. Using Windows Live Messenger (for Josiah) and Adium (for myself), we are able to constantly be available to each other.

3) Drop Box - For easy transfer of files

4) XCode / iPhone SDK / Cocos2D: These are the tools that I will be using to write the code and test it. I am using the Cocos2D engine to allow for quick development, so I don't have to spend a lot of time mucking about in OpenGL to get things on screen.

5) Josiah is using some less than standard software: where many artists would turn to photoshop, Josiah is using what he describes as "a weird obscure piece of engrish software that I can only assume is named "character mucker 1999" but otherwise seems to have no title", and modplug tracker for music and sfx. He is also using 'Cool Edit Pro 2' for mixing and mastering.

The Final Words

Is what we are attempting even possible? Can two individuals really give up all of their free time, and perhaps much of their sleeping time, for 8 days, just to make a single product on the side of their other commitments? Success or not, it's going to be a wild ride - but Josiah and I are determined to push ourselves and prove to ourselves we are capable of anything.

182 hours remain between now and the end of our project cycle. Time allowing, there may be more blog posts outlining our processes, where things take less time than we expected, where they take more. With luck, next Thursday there will be a post mortem here describing, in high level, just HOW we turned a quick prototype to a full fledged product in just 8 days.