Last week was filled with creating threads for feedback and reviews of all the different speedgames. The only one I didn't review was my own, but I wanted to make a thread for it anyways. I'd love to hear feedback on Finding Keepers from anyone who played our game.

The other great thing about these threads is that it is a perfect place to put a post-mortem about the project. I didn't take a whole lot of time for mine, but I wanted to write down some of my thoughts about the project and post them. Just as external feedback is an important part of learning from the speedgame, I think internal reflection is important as well.

I think my partner Charlie is planning on posting a post-mortem from his perspective as well, but for now, I'll just post mine:

Finding Keepers (Mac version) -- (by HanClinto and Charlie Mauck)
---------------------------------

Post Mortem by Clint

Introduction:
-------------
Wow! The CCN Speedgame -- one of my favorite contests of the year! We would have two weeks to create a game on a Christian theme, and I was really looking forward to it. Back in July at the Christian Game Developers Conference, I spent a good amount of time talking with my friend Charlie Mauck about game design and whatnot (primarily about a larger game project we're desiging with some other people). I have a lot of respect for him as a game designer, and when the announcement for the speedgame was coming up, I asked him if he'd be interested in collaborating on a project together this year. He was interested, and so we joined up. I had been thinking earlier in the summer that I wanted to make a small casual game this year -- to just pick something very small and complete it well. Charlie was totally on board with that, so that's the criteria we started out with -- a small casual puzzle game, preferably tile based.
The theme was a hard one to work with for us, but we both thought that the parable of the dragnet was one of the better options for doing a casual puzzle game. So a day or two before the contest, we had settled on our idea and were hashing out gameplay suggestions. On the first Friday night of the contest, I think Charlie stayed up most of the night typing up our multi-page design document and working on fish art for me to use.
One of the other main goals that I was really shooting for was to make something that looked like a professional-quality game. Eye candy was pretty high up on my list this year, and I wanted to keep that in mind from day 1.

What Went Right:
----------------
1. Early drafting of design doc
Those early all-nighters that Charlie did really paid off in spades for us. I don't know how many he wound up pulling for the whole competition, but all of the effort that he put in to get our design solidified was just incredible. It wasn't a perfect design doc, but it was invaluable in helping us resolve conflict and focus on a common vision together. Getting the design doc drafted so quickly meant that we had a roughly playable game within just a few days of the start of the competition.

2. Lots of communication
I need to look at my phone records -- I would love to know how many hours Charlie and I talked on the phone during those two weeks. We talked nearly every night (and often in the afternoons as well), as well as many e-mails back and forth to keep track of our priorities. Working with teammates is always hard, especially when the designer is a different person than the programmer, and both parties are over a thousand miles apart. I had to work pretty hard to subject myself to his designs, even when I would have liked to do it differently. It was a great learning experience for me to be a better team-player as opposed to just being a Maverick (a cocky lone programmer who doesn't work well with others).

3. Consistent design paradigms
Going along with making the game look professional, I put a fair bit of effort into making sure that there were never any hard-transitions in the game. All of the screens fade in, menus slide in smoothly, matched fish spin off the screen while new ones fade and slide into place, etc. It was also important to me for the game board to not "lock" as it's updating and pieces are shifting around, so even while pieces are sliding around, they are still clickable and you can clear stuff from the board as fast as you can click on them. We have one very intermittent bug that we've seen show up with this, but other than that it's proved to be a pretty solid system, and I really like the natural feel that it gives the player. It's not the kind of eye candy that draws attention to itself, but as I learned, it can be very hard to make sure that every little thing in the game behaves smoothly like this -- there is a *lot* of work that goes into making a game look professional, and I'm extremely glad that we kept this goal in the forefronts of our minds from day 0.

4. Great tools
I don't think I can speak too highly of Torque Game Builder -- it's a fantastic tool that aided our development so much. I was on Mac, while Charlie was on Windows, and we were able to do cross-platform development very seamlessly. It's a fantastic tool that greatly boosted our productivity.

5. Very small scope
Both Charlie and I are married and have full-time jobs, so we weren't able to put our lives *completely* on hold for this project. As such, it wound up being very good that we had such a small overall scope for the project. Because of that, we were able to get our first playable version done within a few days of the contest. This left us a week and a half to polish it up, and it was incredibly valuable for us. Even though it was a small scope, we still had a ton of things to implement, and we didn't even wind up getting everything done. The cutscene engine only went into the game on the last Saturday, and we didn't have time to put in the sound effects that we had recorded. I don't think we would have been nearly as happy with the end result if we had picked a larger project.

6. Early asset creation
Charlie did a great job with the artwork, and I was rarely waiting on him for assets to put into the game. I had to make a few pieces of programmer art (if you beat the last level, you'll get to see some of it), but usually I could just use final (or near-final) assets in my development.

7. Lots of testing
Charlie did a great job of recruiting a lot of testers for the game. It helps that he has a lot of kids. He set his crew doing QA starting Thursday or Friday, and having a couple full days of testing really helped us find bugs and balance the gameplay near the end.

What Went Wrong:
----------------
1. Unfamiliarity with tools
I spent last year's contest struggling to learn Torque Game Builder, and so coming into it this year, I was very familiar with the tools we were using. Chalie on the other hand, hadn't done much with it before, and so this year was his big learning experience as far as that goes. He also spent time learning the intricacies of Gimp during the contest as he was pulling all-nighters, fighting with transparencies on the artwork and whatnot. Charlie's incredibly sharp and talented, and was able to get pretty good with them by the end of the contest, but it was pretty hard slogging for him in the beginning. Granted, part of the value in this contest is the motivation that it gives us to learn these new tools that we've been "meaning to get around to learning" -- so we can't have many huge complaints there.

2. Not enough GUI sketches
Don't get me wrong, the design doc was *fantastic* and absolutely invaluable. It was easily one of the best design docs I've had the pleasure of following on a game dev project, but if we had more time, I think it would have been very worthwhile and valuable to have more polish on it, specifically in the area of mockup sketches. The hardest thing was how the GUI design was communicated through it -- we had one sketch that guided most of our in-game GUI development, but if we had had more mockups and sketches early on, that would have saved us some rework as far as the GUIs were concerned. Charlie and I are both very much in agreement that we need more sketches in the future. It's the only reasonable way we can see distributed development working.

3. Time budgeting
I didn't do a terribly great job of budgeting my time for the development, and as such, I perhaps should have added some key features earlier on in the design process. It wasn't a good idea to add the cutscene engine on the very last day, and I'm disappointed that I put off adding sound until that day. I figured it would be a quick and easy thing to add, but as always, there were some hiccups, and we didn't get everything in. Still, I'm really glad we got done what we did, but suffice to say that I've gained some more experience in what it takes to finish up projects.

Conclusion:
-----------
All told, it was a fantastic contest. I was extremely happy with how it all turned out, and I'm very thankful to have been able to put on a good presentation. As I've said before, I absolutely loved seeing how everyone in the contest improved so much -- it brings warm fuzzies to my heart to see everyone growing so much. I like looking back and using the contest to gauge my own progress from last year as well -- it's really nice to use these contests as little history markers -- little ebenezers -- to see how the Lord has guided me in my game development process.
Also, this was a fantastic opportunity for me to get to know Charlie better. I first met him a little over 2 years ago at the 2005 Christian Game Developer's Conference. We got to hang out after the 2006 conference when he took a number of us on a beach trip for the weekend after the conference, and that was when I first got to know him. At the 2007 conference a couple of months ago, we spent even more time hanging out and talking together, and I'm so thankful for the opportunity to complete such a short-term game development project with him and build the friendship.

I'm really thankful to the facilitators of the contest (admins and sponsors), as well as to the Lord for placing us all in such a community where we can grow and commune together with our hobbies in the name of our Lord.

In Christ,
clint

Edit: Slowly revising the writeup.

[This message has been edited by HanClinto (edited September 04, 2007).]

Edit: sorry my bad the other release was for mac not linux unlike I thought first.

Here's the link to FTP folder (for anyone who needs):
http://www.gameace.org/~CCNcontest07/Herron_Mauck/

------------------
Psa 32:5 I acknowledged my sin unto thee, and mine iniquity have I not hid. I said, I will confess my transgressions unto the LORD; and thou forgavest the iniquity of my sin. Selah.

[VoHW] (Help needed) [Blog] (Contact) - Truedisciple (mp3)

[This message has been edited by jari (edited September 04, 2007).]

I wish you the best on your future endeavors! I honestly think you and Charlie could take the cake in other game competitions as well.

God bless you both!

btw, I'm still working on my own postmortem for my game as well. With all you've had to do, I congratulate you on getting this out so quickly.

------------------
Sam Washburn

Check out my CCN SpeedGame 2 Blog

Samw3, thanks for the encouragement. I'm glad to hear that you're enjoying playing the game. We've continued to work on the game -- I just added some more particle effects and unlockable progress last night. Charlie's been busy making more levels, especially since we added the ability to make differently-shaped boards last week. I don't want to give too much away, but I think we're shooting for a final level count of 50.

We've submitted it to a number of casual game publishers for feedback, but we haven't heard too much response yet. We wouldn't expect them to publish the version we made for the contest, but we thought it would work as a good pitch demo. We're trying to figure out how much it would take to get this up to the level of quality needed for publishing.

In Christ,
clint

------------------
Psa 32:5 I acknowledged my sin unto thee, and mine iniquity have I not hid. I said, I will confess my transgressions unto the LORD; and thou forgavest the iniquity of my sin. Selah.

[VoHW] (Help needed) [Blog] (Contact) - Truedisciple (mp3)

Are you saying that you have seen a problem with the hint button? Or were you just saying that you have a hard time on the tougher levels, and use the hint?

Thanks for the feedback!

--clint

quote:

---

Originally posted by HanClinto:

Or were you just saying that you have a hard time on the tougher levels, and use the hint?

---

Yes that's right.

------------------
Psa 32:5 I acknowledged my sin unto thee, and mine iniquity have I not hid. I said, I will confess my transgressions unto the LORD; and thou forgavest the iniquity of my sin. Selah.

[VoHW] (Help needed) [Blog] (Contact) - Truedisciple (mp3)

------------------

My points are much the same as Clint’s, but I’ll format them differently so it doesn’t look som much like I just copy-and-pasted his notes:

Scope:
--> The Good
We decided right off the bat that we wanted to create a game that was not only reasonable to accomplish in the time-period, but that we could be completed well. We really wanted something that we could put a more professional polish to, and thus we planned our scope right from the beginning to be very small, with a very limited number of features.
--> The Bad
Once we’d made it through the core features (amazingly enough), there was a bit of thrash deciding what additional features to add. The design doc had some ideas for features that were beyond scope – just because they were worth mentioning, and missed out of some low-hanging fruit for easy additional features. Our priorities doc came through for us, but we probably should have incorporated a prioritizing system earlier.

Design Document:
--> The Good
Having a solid, early design document was a major help. It cemented the vision early for both of us and provided a way for Clint to quickly look up how things were supposed to work, without having to get me involved often.
--> The Bad
In hindsight, this was so valuable it makes me wish we had even gotten more of it done before the competition started. Even thought Mack had opened up the possibility of starting on it earlier, I really didn’t get committed into the project until right before the competition started. I certainly could have saved myself at least one all-nighter by having the document done and reviewed sooner.
--> The Ugly
As Clint mentioned, the section defining our menu system was woefully inadequate. The design document specified the menu system by describing verbally. Unfortunately, much of the menu description was thus ambiguous at best, and at times contradictory. Having actually draw the menus out graphically ahead of time, and coming up with an unambiguous way of describing menu item actions would have saved us much time.

Communications:
--> The Good
Clint is an extremely affable guy, and even under stress he was very easy to work with. Both of us are rather unflappable, so we were generally able to keep a focus on what needed to get done, and get through it. We spent a lot of time on the phone, and although I at first felt it was too much talking, I quickly realized that it was far better to get it right the first time, than have to rework stuff later on. Clint did a great job of dragging the needed details out of me.
--> The Bad
Any team project is a little more difficult to work with, and one in two different time zones becomes even trickier. Being three hours apart meant that we couldn’t both sit down in the evening and talk together. This resulted in a lot of late night calls or early morning calls to get details worked out.

Technical:
--> The Good
Clint did an amazing job of pulling off all the features needed in this game. I’m not quite sure how he did it – and I assume it involves multiple all-nighters – but somehow he dropped in almost all of the periphery features (like cut scenes, backdrops, timer, hint button, etc.) in just a couple evenings in the middle of the second week. He absolutely blew me away with his technical ability there, and it also represents a familiarity with the tool and the ability to get a lot done in it.
--> The Bad
I, on the other hand, spent a lot of time just figuring out the basics. Certainly better familiarity with the tools can lead to a more polished product. On the other hand, a major factor in entering a contest like this is to have the motivation to learn new tools.
--> The Ugly
One big hindrance to our progress I found was that Clint doesn’t have Internet access from his home. I had thought that the time difference would have been an advantage for us, because I could pick up where he left off in the evenings, but without internet access, I would not get the latest version of his progress until the subsequent morning. This led to a sort of slow feedback loop, where changes I was making in the art would not be able to be tested until a day later. Part of the struggle with this was that I didn’t figure this out until about halfway through the project. Having worked out a better change and release cycle would have probably made us more efficient and saved us some time.

I could probably ramble on and on, but it's getting late. I'm just really happy with how it turned out. As we are planning on cranking out a more polished v2 at some point here, please give us feedback on what we should be adding for features, and what needs changed.

Thanks!

[This message has been edited by charlie (edited September 10, 2007).]