POST-MORTEM
Itch.io Link:
https://koalazub.itch.io/dish-pig-dilemma
The production cycle of Dish Pig Dilemma was full of problems throughout the development of the game, which was largely tech, programmatic and software based issues. This post-mortem will detail the varying aspects of the project and what went right/wrong and what was gained from the many failures during the trimester.
What went right?
It seemed a miracle to be able to demonstrate any sort of functionality in the last week. By the end of the trimester, we were able to demonstrate what really should be considered an early prototyped/alpha mechanic system.
From a project management perspective, the team consisted of a total of 10 members by the end of the game’s life cycle. Thanks to early planning in both documentation and team hiring, we managed to start off the project somewhat okay. We had difficulties securing an animator/rigger early on, but this will be discussed below. Each team member knew what was required in the project, and what work had to be completed. Weekly meetings and almost daily contact ensured for the most part that everyone was up to date on the progress of the project and any immediate issues. This level of transparency was very important and saved much time from having to consistently repeat what is needed week to week. Weekly meeting minutes were made available for both the weekly ‘main’ meeting and the graphic designer meetings when they occurred, which further aided in solidifying project expectations. Communication amongst the team members was very good. Despite the massive hurdles, the team persevered in trying to complete everything as intended. Also alternative solutions should have been sought out, the team is to be commended on their hard work at trying their best to solve the myriad of issues.
From a visual perspective, the project looked great. The models for both the kitchen and main character, ‘Spud,’ were on point and truly managed to capture the themes and ideas that the game was trying to implicate, which was dirty, grimy and chaotic. Spud went through several iterations over the development period, mostly due to rigging and importation issues surrounding Unreal Engine. In addition, all work from the graphic designers was of a high quality that seemed to fit the concepts of the game. In this particular project, we as a team were open to any idea for UI/HUD and general menu aesthetics as long as it fit the criteria of being in line with the ‘flat, warm almost cell-shaded’ style of the game, and they successfully managed to create assets that fit this criteria, as well as going above and beyond by providing several variations, that would have been used in the game if there weren’t as many issues along the way.
The switch between dirty and clean dishes, as well as the spawning of random dishes was successfully implemented, as well as the intended ‘sticky’ grab and drop style controls. Unfortunately, issues remained with the placement in a clean dish rack, which was one of the final hurdles of the project.
The audio sound effects in the game were completed early in the production, and worked well to supplement the game’s menus as well as what would have been intended in the main level(s). Unfortunately, our audio person became slightly overwhelmed with their workload and fell slightly behind, however was successfully able to acquire support and assistance from another audio student to keep the project going.
What went wrong?
There were numerous aspects of the project that went catastrophically wrong. There were two key areas of the project that were deemed the most problematic: GitHub integration and getting the mechanics sorted for a rigged model.
GitHub was a persistent issue throughout the duration of the trimester. None of the team had previously used Git to any extent bar for basic research, however given the fact that the engine that was decided to be used was Unreal, it seemed to be a no brainer that this was the type of source control we needed. The learning curve of Git seemed very problematic. Initially, upon downloading and linking GitHub Desktop to the Git repository, we thought that everything was working fine until it came to the time that we need to do our first set of pushes/commits. On different devices we were getting errors that there were no traces of the project (OR similar) errors. This resulted in us having to forcibly push and pull the project from Git servers via Command Code, which was mildly terrifying to say the least. To add insult to injury, due to our lack of knowledge on how the push/pull/merge ‘exactly’ works, we were unfortunate to re-write the project at least 4 times, which greatly hindered progress from a programming point of view. To help risk manage Git, transfers were basically kept between two devices with multiple backups being kept on both in the event of any accidental misfortunes.
The game called for the direct control and manipulation of the character’s arms from the elbow joints. The original idea when conceived did not consider using a fully rigged model, but rather a series of basic models that were all connected to parent objects, which would hopefully flail around in a comedic fashion. However, after discussions with a programming lecturer and with our programmer, it was decided that we would go down the path of direct joint manipulation in a rigged model. This of course opened an entirely new can of worms in the process, as no one had previous modeled anything above a building little own a full or half character that required rigging. Our designated character modeller, who was looking at furthering their Maya abilities in this particular area took this on board as a challenge.
Unfortunately, we were unable to secure an animator/rigger when we did group pitches to animation students, as well as during the Crewing Night, however, we were eventually fortunate enough to acquire an animation student who had been more skilled in rigging and animation then some of the others. A new skeleton was produced for the model, as well as some basic head animations, however the next issue came from trying to import these into Unreal, where everything seemed to lose connections and just not work at all. This resulted in several remade iterations of the Spud character (At least two to three) until we managed to get a skeleton that would work (With no animations). It seems that some of the issues with this may have arisen from using Maya on various computers, despite being the same version.
Further to the above, programming for the controller inputs was handled largely using the default character pawn in Unreal, which had a much more detailed rigged skeleton than that of our own model. This led to much confusion and required further understanding of the mapping of bones in the mesh hierarchy. Eventually the imported working character was able to have it’s joints mapped somewhat successfully.
A gigantic part of the project was spent waiting on the mechanics, namely the character mechanics. Too long in fact. A contingency plan should have been made much earlier in the development cycle as a backup. However, it appeared that for every time progress would be made, suddenly something completely different would break, sometimes unrelated to the original issue. Unfortunately the method of programming the character was well above any of the designers’ collective skill sets, and was also new to the programmer. This of course limited support to our programmer as well. Our programmer is definitely to be commended in tirelessly attempting to work on solving each and every issue as they arose, and spending extra hours on the project well above what is expected. As a team, we tried to crack the shell on the mechanics, but sadly failed in this instance, but coming out of it, we still at the least have a bit more familiarity (Especially the programmer) on how character skeletons/models actually work, as well as understanding that we need to look for warning signs much, much earlier.
More minor issues encountered included having to drop the idea of ‘destructible meshes.’ These would have shattered the physical mesh of the dishes when being dropped, however it was problematic trying to switch between a static and destructible mesh, hence dropping this idea. The placement of the dish into the clean dish rack was one of the remaining hurdles that needed addressing, however was sadly unable to be implemented in time. Placement of the character and level assets causes some clipping of the character through the bench, which looked...odd. The meshes of some of the more complex items such as pot and pan would sometimes get locked on the character’s left hand permanently.
Due to the above main issues, this had a bit of a roll on effect on the remaining aspects of the project. For example, the intended high score leaderboard was unable to be implemented due to not being able to track anything and intended control scheme help menus not being complete due to unresolved/un-mapped controls.
Obviously due to the fact that we were never able to get a build of any kind, testing was impossible for this game.
What was learnt?
Much came out of this project. Out of the successes, further knowledge was gained on texturing and 3D modelling skills. One major glaring issue that seemed to have been figured out was how to correct the pivot points from Maya to Unreal or Unity upon exporting. Previously the pivot points, once imported in engine, would appear no where near the object. We finally worked out how to correct this, which ended up being really important on this project due to how the hands grabbed items.
Despite the Git related issues, a further understanding on how repository services work was developed, as well as (eventually) some sort of understanding surrounding Git. It was learnt that Git is quite volatile, and one wrong move can drastically destroy or hinder a project. Out of this, we found that, through suggestions made via a programming lecturer, that Perforce seems to be more commonly used in Unreal development. This is something we can look into on future projects.
An understanding on how animations as well as rigging work within Maya was developed by our character modeller. This will be valuable to him as he can take this into future projects, which he did with his second game, as well as able to help guide us, his peers, and share the knowledge he learnt over the course of the trimester.
Major thing that was learnt was that contingency plans need to be put in place much earlier in the development period, regardless of our own goals. We ended up basically fixated on the work we had made that it got to the point that we felt as though we were too far into it to actually be worth changing. However, in a paid environment, we would have potentially lost a client.
This was the largest team that we as a team had likely worked with (Was certainly for myself). So it was a refreshing challenge to try and work with students from multiple disciplines and skill sets and try to motivate and foster work that is appropriate for the project. Good relationships seemed to be formed with all involved, with some looking forward to working on future projects again, despite this project being more or less a failure as far as a release goes.
This project is the perfect example of how it sometimes doesn’t matter how much preparation and clear documents you have, persistent issues can be enough to cause timeline slippage that can inevitably spiral out of control. Identifying ‘points of no return’ sooner in the development cycle would have benefitted the project greatly.
What would do different?
As discussed above, early ‘alternative solutions’ should be discussed. If this project was to be remade from the ground up, I would discuss, or better yet, try to prototype 2-3 varying methods of the mechanics in question to see which worked best and what each of the versions pros/cons are.
Identifying near misses or points of no return ASAP to devise and implement alternative measures sooner. Remaining mindful of any milestones/deadlines. If these aren’t being met sooner, perhaps alternative features are required.
Research more thoroughly the optimal programs to use for source control, and weigh up the pros and cons of what works best for the team. Going in unsure of Git, we should have had more backups of the project, which would have eliminated the issues we had of losing progress 4 times.
Personal Note
As for my own development throughout this trimester, I feel that my interpersonal skills and team/project management skills improved immensely. Despite all the failures, this was an invaluable experience of something that occurs very, very often in the game development world. I feel that I managed to try to keep morale of the team (And myself) going despite all the issues. At the end of the day, some issues cannot be fixed if we are under-skilled...or...if technology has a mind of it’s own.
Despite this, I managed to not ‘buckle’ under the pressure, and remained vigilant in trying to keep the project on track. If anything, this project definitely taught patience, as well as boosted confidence on pursuing foreign ideas that I have previously never played around with. This greatly pushed me outside of my comfort zone, especially in some aspects of Unreal, in which my skillset is not as strong as I would like there. Seeing Ali’s programming in this alone made me realise that I still have a long way to go and a lot to learn, regardless of being a designer or programmer.
Not having a final build, as well as battling against my own timeline/Gantt chart due to mechanical issues was somewhat disheartening, and at times it often had me questioning my ability as a PM, however I feel as though I, as well as the rest of the team, did the best we could, and learnt valuable lessons, as discussed above. The experiences gained during this project will be undoubtedly used and considered in each and every single project going forward.
Although remaining unfinished at the point of this submission, Ali and myself plan to try and demonstrate the game at the next IGDA meeting on Tuesday the 9th May. It could be rather insightful to hear how other devs may have tackled some of the issues we were presented with, as well as how they would handle them differently.
