Paddlepop the Pyrata - a Postmortem

In this blog post I want to take the opportunity to write a little postmortem on the last project I've involved in called Paddlepop the Pyrata.

Paddlepop the Pyrata is the second in the series of promotional games, created by Cyberplanet Interactive, that is done for the icecream product called Paddlepop from Walls and was recently launched in August 2008 as a freedownload (or you could exchange icecream sticks for a CD copy). I was drafted to join Cyberplanet-Interactive as a Technical Lead in the Paddlepop the Pyrata project.

I want to give a litle introduction to the project, some screenshots, before I end it up with the postmortem.

Introduction

Paddlepop the Pyrata is basically a 3D adventure game, in which you control one of the two characters, Paddlepop or Liona to collect 3 special icecreams through 4 unique game worlds so that they can drive back the hordes of the ShadowMaster back. The game is aimed towards younger game players, so it contains a number of irrelevant puzzles that serves just the purpose to break the gameplay and allow the players to practice basic problem solving skills. You can learn more about the game by visiting www.paddlepopadventure.com.

You can download the game directly through the websites at www.paddlepopadventure.com/pyrata/download/game_pyrata.exe (Windows only!).

Sample Screenshots

You can find more randomly hastily acquired screenshots at this url: www.pigcanfly.com/PaddlePop/

Development notes
One of the first issues the team faced was the problem with the short deadline. Our team was given a 2 month deadline to come up with the product by the specification for the CD factory. For a 3D game, that is a very short deadline, so we had to pick tools that we know well and manage the risk. In this project I chose TGE as it answers many of the questions, and I had experience with a similar project (a few of my old blog post talks about it) earlier.

In the production side, there was a number of people. I was the technical lead making the necessary engine modifications and scripting. I had two assistant scripters, one of them worked mainly on effects and dev manager(Phot) and the other on AI(Kong) and have worked on TGE before. Interestingly, we had only 1 artist (Zun), who worked on the gui, models, animation, and cutscene cinematics (6 short scenes) who never worked on in-game art assets. We had a level-designer (Nhum) join later to implement the level design.

In addition to that, we had a soundtrack composer(Mark) and another composer that composed the cinematic tracks. A game design team (Can and etc.) and management team (Orr.) was involved in the general direction of the project and contacted the customer. At the last month we had a very dedicated QA team that helped bugs that were overlooked.

For this project we were asked to make the game run on the most varied computers as possible by not using shader technology. Due to that TGE was quite a good fit, but I could not use the latest branch of my hacked TGE with lots of graphical modification on that. We ended up starting with a vanilla 1.5.2 mod with arcane.fx add on.

Issues of concern
Based on the schedule, we were worried about the art production that might hold up the rest of the production. Based on previous experience, our initial estimate of the art asset would require at least 3 months to finish. To help alleviate the situation, we have informed our artist that it might be a good idea to procure some art contents for level decoration to help lower the art requirements. In addition to that, we had a priority system to list which assets are needed so that as much work could be done in parallel without having to wait for each other. We started on a level by level basis, the game AI objects are done first stage by stage so that the scripters could script the behavior of the object, and the game decorations are sent later so that the level designer could lay down the level next, when the dev clean up the behaviors.

What went right?
- Version Control System - as many people in our team are contract workers, we had to merge content from places to allow work to progress quickly. A webbased SVN server helped us in this aspect tremendously. For example, our artist was happy that he did not have to get out of home when changes are required.

- AssetList and Priority - spending time on the asset list and their priority helped keep the schedule on target as assets are delivered close on plan.

- Our artist is a superman - how did he get it done in time?

- Melee System - we ended up using a customized melee system. As our melee system is loaded in animation, we found that we can fake accurate melee resolution (e.g. like MMORPG games). Instead of the ray-trace or the box to box collision, we just simply modified the explosion resolution algorithm (yes that one in the starter.fps). Simple and effective :P

- Level Design - having a dedicated level designer helps! Luckily for us, our level designer had TGE experience (used to study with me :P), and had great artistic sense. To be exact, he managed to make the game look much better than we anticipated. p.s. great art is more important than techincal excellence in making a game look good :P

- Parallel Development - we tried to parallized the dev process as much as possible so that no one had to wait for each other. This help reduce overhead.

- InGame Tools - We embedded a number of utilities such as spawning and level controls in the game. This allows us to quickly unit test certain AI or game functionality.

- Debug/GameMode Flags - game debugging and mode selection could be easily switched by scripting. This allows easy conversion from a game with debuging tools turned on into a release build quickly.

- Localization process was planned early - we had a rough localization system planned, though we ended up using only pictures for all text resources so that we don't have to worry about consistency. Changing language was easy by using batch files.

- Extensive testing and QA - the QA team found many obscure bugs for us.

What went wrong?
- Time - in 2 months we were able to release a working game based on the features listed in the requirement, but there were a number of bugs that were not discovered. During the QA testing that was done in the 3rd month for the English version, we managed to weed out most of the crazy bugs in the game. However due to the schedule, the local CD version was lauched without a few of those bug fixes though the online download contains most of the fixes.

- QA started too late in dev cycle - We intially wanted the QA to start during the development phase to the end, but it was not granted as it was expensive, and we ended up having the QA process on the deadline.

- Exporting problems - Our team faced problems in exporting certain models for the game. Our artist had a difficult time exporting the models, and one the scripters was assigned to assist and help export some of the tricker models. We had snags with a few models, but luckily we had a few friends at Chiang Mai that helped us, so we lucky :P

- Random Crashing from huge time delta in Foilage System - in the foilage system, it seems that a huge time delta could potentially crash TGE 1.5.2. We had a time test to see how long the game can go without crashing, and it ended up that heavily foilaged levels crashes quite frequently (1-4 hours of pause). Luckily the debugger was there so I was able to make quick patches to that to limit the maximum time delta allowed to fix the random crash problem.

- Minigames are a hassle - we had to work on 4 minigames. They ended up taking more time than on what we spend on the main game play after debugging and all. I would have prefered to spend that time on the minigame to further improve and refine the game play

- OpenGL Issues - I written a short article about my frustrations with OpenGL when deploying in an external website: forums.thaigamedevx.com/index.php?topic=1763.0 . Not sure if you could see it without registration, but could duplicate that here someday. Thought I was getting too chatty.

- Changing requirements - We had a number of major requirement changes including adding an additional playable character, changing fighting system, an online highscore system, and a number of changed minigames late in the development cycle. These changing requirements on a tight deadline is bad for morale and quality. We ended up having to compromise certain features to make things work.

- Bad Documentation - all the scripters had a nightmare working on other people's code. Due to tight deadlines, code documentation was sparse and lacking.

- Resistance to Version Control Adaptation - some people will refuse to utilize version control and practices vary from user to user. Maintaining good usage policies is difficult.

- Compromises - more features + less time = less refinement We ended up having to cut a few corners on refining the game. Some features had to be done before the external infrastructure is ready. As most are very specific, I'll not write about them here.

- No Vista Support - had no time to check it works on Vista extensively.

- Freetime - You must be kidding me LOL

Conclusion
We are happy with the Paddlepop the Pyrata project. Our team managed to conjure a 3D game up in a very short time and it looks pretty good and plays pretty well at the end. My regret is that we did not have more time to polish things up. However as being better versed with the business world, I learnt that is just a fact of life. To be exact as working as a contractor for a while, ego is one to throw out the window as long as you aren't endangering the life of people :P

Regarding the game details, as it was launched yesterday, I haven't got much info of it eiter. Maybe later I'll update this if anyone is interested, though I suspect it'll lack any information people would be interested in :P

Until the next time, ciao!