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.
1 comment:
Congratulations on completing the game.
Post a Comment