In order to celebrate this highlight, I'm publishing the Post Mortem from this project below.
Post Mortem: Home Riders - Escape From Coliseum
By Yves J. Albuquerque
Home Riders was the first 3d game for Samsung SmartTV made in Unity. For any experienced developers this first sentence smells like problems but with about 90 days to complete the project this was far from being our primary obstacle. The game has a small list of requirements, some of them includes being impressive to be showed as feature in selling points for the Curve UHD TV.
With the huge complexity of the project in mind, several concepts was elaborated, filtered and submitted to the guys from Marketing. Once there, Home Riders was rebuilded and the final concept was ready to be executed.
Actually, since the first day of the project, it becomes very clear that this project was impossible to be released as expected but our deadline was linked with the last marketing campaign launch so, even knowing that It was a impossible job, failure was not an option, as change the deadline either. So, even being an App Team becomes clear that some help will be needed in order to finish the game. No one, except myself, had previous experience with 3d game development so two crash courses was organized before the project officially starts so the crew could be a little more familiar with the used technology.
From the beginning of the project, only myself was involved but as the deadline comes closer some reinforcements comes as expected. First, Paulo and Vilmar was added to reinforce art team, then Rodrigo and Emerson was partially allocated to help with the programming. By the last weeks, our team receives a two-days help from Black River guys which hugely give us a necessary boost on the final lap.
Home Riders was released on 2014 Top TVs (the target one) on November/2014 attending an immovable deadline. Some improvements was done on December/2014 and, since then, the following months are marked by several releases increasing the platform scope.
What Went Right
1. Preliminary tests
As a unexplored platform developed surrounded by secrets no one knows what kind of challenges will be faced. Even the hardware that we are dealing with was a mystery at that time. Nothing like that was done before and no one could answer simple questions as what`s the graphic card used on the TVs. It take a while to put together all the small pieces of sparred data until something makes any sense.
Then I start to test on each TV in order to discover more about what we are dealing with and their boundaries. While that happens several messages changed with the guys from Unity helped both side advance and improve overall performance. At the end, I had a table with each chipset used on 2013 and 2014 TVs and their boundaries.
This information had a great value and helped, if not in explore the hardware limits, to be conscious of the size of the problems we`re facing.
2. Assets Optimization
Without a huge background on mobile development, I know that we`re challenging something closer to that kind of development, so it was obvious that we need to optimize something. Unfortunately the current experience in 3d art production of our art team was none. Ask for optimized assets has the same impact of ask for a huge and expensive asset, so it becomes clear that I`ll need a second way of optimize things.
In order to have something smelling like optimized, from the design point of view, I reduce the variance of obstacles and choose a very narrow texture palette distributed in a few materials. So far, that was the farthest I could go without make our artist jump thru the window.
At first, we adopt the strategy of buy some ready-to-use assets, modify then and put inside Unity. Once this strategy give us a lot of really heavy assets, it also permit a fast game preview. Then, some 3d art starts to be done in-house, with myself doing a two-minute cleaning in each one of them, and trying to put everything above the same art direction umbrella. About September, most assets are done but in a terrible and expensive way.
On the last month, with some help of Black River, several optimizations are done in order to run Home Riders smoother and several assets was revisited.
After the first release on November, I could turn myself to the art optimization problem and continue the boost started by the guys from Black River gaining 30 fps which was converted into anti-alias and a Full HD version on top TV models. For that result I used some LOD tools as Sympligon among others.
3. Learning Curve
The App team learned so much of 3d game development that all member talked about how much they learned on that process on out Post-Mortem meeting. Not only because the crash courses we did before the project starts but by the hundreds of feedback received over the entire process.
For myself, personally, several tips on that two days with Black River helped a lot to see new solutions which have a huge impact in newer projects.
4. Fixed Deadline
We have a rigid deadline since day one. Even being a preannounce of a failure, we grab this deadline and make a huge plan trying to fit our impossible project into it. The initial concept has 4 game levels being the two initial levels, the released ones.
About the two remaining levels, one are all done and the other have all their 3d assets in place by the time we had to cut the project and throw them away about 20 days before the final release. A cutted mini-game was also implemented and waiting for the final assets by that time.
For a impossible game, we are almost there and probably with two or three additional weeks we could release the entire planned concept. If we think about the two weeks delay on asset acquisition at the first part of the project, maybe the project could be released complete with a little luck.
5. Black River Reinforcement
With less than 20 days for the final release, Home Riders could barely run on the target TV, due by other things, the expensive art. At that time, there was a very few things I could do to accomplish a better performance and since I was full time finishing the game levels and programming, It looks like nothing could give the necessary boost on our project.
Fortunately I kept an open dialogue with my coordinator and with my manager, who gives the Idea of calling for a little help for the guys from Black River.
While I work at the App team doing games for SmartTV, Black River is my counterpart on mobile but instead of one guy, they have a nice experienced team producing AAA mobile titles. By some company restriction, due confidentiality, usually there`s a barrier between both teams. They even don`t know about my existence on the upper floor since my manager call than for a meeting.
We showed our project to the guys from Black River and, for two days, our team was twice bigger and have several experienced guys helping put Rome Riders on the trail by adding effects, sounds, cleaning meshes and doing a huge boost in lightning setup.
What Went Wrong
1. Early dev
As an early developer using Unity for Samsung TV, several issues was detected and steps on our way. Some issues, as the incapability of play video format on TV, impacts our initial concept and we couldn`t ignore them. We tried very hard to workaround this problem but no good solutions are founded without represent a huge impact on the final release size. So we re-designed our solution to fit our restriction. All the process took an relevant amount of time which represents a huge step back in our production.
In a second phase, Home Riders was developed using Unity n-screen and uses the network system in a very early version to communication with mobile. While convergence was not a requirement, we was able to implement that feature as an extra for demonstration purposes. Unfortunately, we need to take down this feature before final launch as it was detected by the security tests and there`s nothing about it on the docs.
2. Deadline restriction
As mentioned earlier, with a little flexibility, two or three weeks could represent a twice longer game with richer history and gameplay variance.
3. Inexperienced team
Home Riders starts with me but several other joined their forces in order to make everything happen. However, experience was an issue. Each team member helped a lot but also increase my job and I become a little over-allocated by the end of the project. Since the team have a huge progress rate and a very angled learning curve, their productivity are a little compromised.
Since this was an expected behavior, tasks and tools are chosen in order to reduce the failure rate, unfortunately, one of than results in the exactly opposite behavior. UMA is one of the best solutions on Asset Store and definitely is a tool of choice if you need a customizable character. So adopted UMA because of the mainly by the huge variation of enemies expected on our mini-game. Also because it comes with a template a is well documented and as our guys are just starting to work with 3d, it represents a way of guarantee some minimal quality on organic models. However UMA is a complex tool for a 3d beginner and when our mini-game was cutted, there was only three remaining characters.
Without an 3d artist able to deal with organic modeling (I was unavailable because of all-the-other-things), we use UMA parameters modifying a brought mesh in order to achieve the desired result. Unfortunately, among our characters, there`s a kid, which UMA don`t have a ready-to-use template available on Asset Store and so our artist had to model there`s parts using an adult template to then be rescaled by the bones inside Unity. Yep, the source of our kid is an adult dressed like a kid.
4. Core based on template
Since we have a very limited amount of time and a well knowed and explored mechanic, I used a little cheat which had helped me a lot on the past in similar situation. We brought some runner templates expecting to use one of them as base for our development.
After compare some solutions, one of them looks much better of the other with lot of probability stuff and editor-side code. Just some adjustments are needed.
This was our worst shot by far. After a while we figure out that the framework being used was a uber- spaghetti almost untouchable, but by that time there`s no way back. We just need to keep going trying to fix our core mechanic as much as we can along the process.
About 70% of the framework was re-written and takes about 50% of the overall dev effort. The remaining 30% was responsible for about 90% of the problems we face on Home Rider release and after that. Nothing can be reused from our code on next project and we still having nightmares about someone ask to fix something related to those 30%.
The remaining core is right in the core of our game and represents a problem to anyone who touches this project. Even the tester pay the price by not being able to test the second level without play the entire first.
GIT is probably one of the best version control solutions and appears in several other project as "what goes right". In our project it acts like the opposite. Actually it`s not GIT fault. GIT is extremely fast and awesome. As a new member on the team, I bring hundred of new things, maybe bringing too many things, and about Version Control, I prefer to ask what the guys preferred to use and GIT was that tool.
So, for me, the first problem is learn how to use GIT. I didn`t have this experience before and looks like command line was the way of doing things here. This was not a problem if we could reduce the number of conflict but do a merge become an everyday fight which takes hours to be done.
With an horrible architecture inherited from our base framework, change a single variable demands run over several other classes including the one being modified for other team members. Also, with a berserk-multi-task behavior on, I was constantly running across the entire project doing modifications and implementing new stuffs all the time, so each commit I done has hundred of changes and new stuff even with few hours of difference.
Another factor against GIT was the scene-prefab relationship of Unity 4. A problem detected on almost every commit generating some unsolvable conflicts.
As the deadline comes closer and closer, we also need to pass through some Samsung quality procedures as several releases for test. Our architecture demands several adjustments for each release in order to put our game ready-to-be-tested and at this stage this adjustments (which includes solve GIT conflicts) could take hours and was done two or three times a week reducing by half our productive time on the most critical part.
We are very proud with Home Riders results. Playing against all probabilities and assuming much more risk than most project, our team could deliver a great game and achieve all the requirements. Was an exhaustive experience but also a richer one. While Home Riders still being released due Seller Site restriction, the name was promoted to an Samsung IP and becomes the first game series on TV. Right now, Home Riders 2 are advancing into the production phase bringing several new challenges binded with the prior title experience.
Version Control: GIT
Tools: Unity 3d 4.5 (Samsung Beta) (n-screen Beta)
Total lines of code: About 32.000
3d tools: 3ds Max, Blender
2d tools: After Effects, Photoshop
Tools: Simplygon, UMA, Infinity Runner
Number of levels on the final game: 2
Number of chariot before the final one: 3
Number of versions of dad before the final one: 14
Number of versions of kid before the final one: 19
Number of versions of gladiator before the final one: 21
Total number of environment modules on final version: 10