We recently released our VR game Mr.Hack Jack: Robot Detective, a casual detective game set in a noir robot world.
As we’re starting to look ahead, I believe it’s worthwhile for our team to discuss what went right and want went wrong in the project.
This is what came up in our post mortem meeting and how we’re planning to act on it in our next project. The points will sometimes be straightforward and sometimes more technical or tool-related.
Development start: 1 December, 2018
Release: 11 May, 2019
Expected development time: 3 to 4 months.
Development time: 5 months including Christmas break and an unusually long Japanese Golden Week due to the emperor’s abdication.
Crunch: Nope, nada, niet! \0/
Core team: 4 people
- Designer / producer / sound fx (that’s me)
- Tech / environment artist
- 2D / 3D artist
Composer: external, Ashton Morris
Interns: 4 3D art interns helping on some 3D props and decals on this project (they had other duties on other projects), 1 animation intern who produced most of the animations of the game.
Update 6-18-2019: here's a trailer!
What went right
Let’s start with the good stuff! There’s less of it!
Short duration of production
The project actually went really well overall! I joined after the team’s previous game, The Last Letter. That production had many issues among which a lack of creative and process direction as there was no game designer or producer. That led to delays and a lack of quality, although the team still managed to release, which is great and worthwhile and taught some important lessons. Those lessons and having a design/producing person on the project seem to have helped a lot in getting Hack Jack out the door in a positive work fashion, in less time and with a reduced team size (a programmer from the team moved on after The Last Letter).
Furthermore, the team felt included in all the design decisions and even though some ideas had to be left aside, everyone brought something to the project.
Feedback on Mr.Hack jack was mostly positive and people understood what we tried to make, most people found it funny and pleasant. There was criticism about the amount of content, some puzzles are repetitive and it’s definitely on the easy side. All things considered that’s better than we could have hoped considering that the production was such a short one!
Art is also something we’re happy about. We humbly think that for a VR game, Hack Jack looks pretty good and there’s definitely an interesting vibe. Timothé our artist managed to come up with cool tools and character designs, bringing that extra personality to a game about robots.
Designing for ease of implementation
Knowing that we would not have a lot of time and our programmer Vong was not super comfortable with Unreal Engine yet, we designed some easy-to-implement mechanics and content that paid off. There was still a reasonable amount of iteration on some things, you can read more about it here.
I wish we could have iterated more on some mechanics but a deadline's a deadline and we tried to fit everything we could and not overshoot by too much.
Production pipeline was generally good
Having Cédric, an experienced Unreal Engine tech artist on the team was essential to getting the game to run decently and to come up with a shader production pipeline that made production more efficient.
The music quality
Releasing on several stores
This is straightforward but it allowed us to compare the stores, the sales, the submission process and lay out plans for the future.
WANT WENT WRONG
And here’s the interesting part!
Originally, we intended the game to be ported to Oculus Go. Unfortunately we will not do it.
It turns out we overestimated Oculus Go hardware by a fair margin. We worked on a port for a couple of weeks and although progress was promising, the uncertain schedule mixed with the impression that Oculus Go is more akin to a mobile device in its reliance on free to play content (or cheaply priced one), plus Hack Jack sales on the regular VR headsets not meeting our targets, all led us to pull the plug on the port. That sucks, especially since we designed the game to work well with Go’s limitations (one controller, etc.).
Time to master Unreal Engine
Our team isn’t the most experienced UE team out there and part of us are more used to Unity. Getting to full proficiency in UE took some time and our way of searching the documentation for information was less than optimal, meaning increased time to fix issues.
We also spent SO MUCH time calculating shaders, especially while working on Oculus Go. I’m probably talking days here! Since then, we heard about ways to distribute shader compiling to several machines which is something we will do.
Naming conventions and temporary files
We had many issues with this. Part of the team is french speaking, leading to some assets being named in french due to moments of laziness. Illogically naming files, making them hard to find when using a search field was also a problem. I’m a partisan of long names that include logical words you’d use to search for them. Naming issues also affected variables in blueprints. Temporary files were not marked and stored as such, leading to tons of dependencies that had to be fixed before shipping. For example, we wanted to rely on shader instances almost exclusively, but when testing out things we noticed that temporary shaders from the blocking phases were used pretty much in every part of the game, copied around and never removed.
Solutions to these issues will only come with more rigor and by remembering what a pain it was to fix these issues in Hack Jack. Also, we're writing a proper naming convention guide.
You should love Git.
But Git doesn't love you.
And it's not exactly beginner friendly. Teaching interns how to use it led to maaaany problems. Furthermore, all team members were using their preferred GUI (Tortoise, SourceTree, etc.) leading to people not being able to help each other effectively in case of problem.
We recently settled on using Git Extensions and to set up an internal wiki with a Git 101 for interns.
We’re kind of stuck with using google drive since our company works with it but I can assure that on some days I hate it with all my guts. The file ownership management is super annoying (try relinquishing ownership of several files or folders...you can’t!!! WHAAAAAT).
Anyway, as I said we’re stuck with. Fortunately we found out about Team drives and Google File Stream (a replacement for google drive’s local streaming client). Team drive have shared ownership which makes my world so much better. It’s not perfect (you can’t copy folders from a regular drive to it for instance) but for starting out a new project it’s good.
An example of the quality improvement over the course of the project
Lack of screenshots
Throughout the development, we didn’t take enough screenshots of the game, not least because taking proper screenshots in VR is a hassle. This caused a lack of material to use in articles and communication (and you need gazillions of screenshots when you start showing your game regularly on social channels). Every person on the team will now install a tool to easily capture screenshots with the touch of a button.
Misunderstanding our target audience
For several reasons (a mix of company management decisions and us being slightly clueless) we decided to do a casual VR game. One thing we understood clearly during the development of Hack Jack is that if you’re targeting traditional, premium VR, you might just as well target core / hardcore gamers directly. When you’re looking at VR big hitters you’re looking at traditional game genres and IPs: Doom, Fallout, Counter strike clones. There are some outliers like Beat Saber of course but the VR market mirrors fairly closely the Steam market (except for strategy games which all seem to fail in VR for some reason).
While the music and robot voices were taken care of by a proper fellow, the rest of the sound design was done internally by yours truly. I am not a sound designer. I think the results are ok-ish but the mixing could be way better if I had any clue.
Our next game will have proper sound design!
Too little, too late. Classic.
We wrote articles on IndieDB, reached out on Twitter, Reddit, Facebook, Instagram. We’re also streaming the development on Twitch every weekday which is fun and leads to cool interactions! And we also set up a Discord when we released the game (again, too late).
That said, no one external to the company got their hands on the game before release. The team just didn’t have enough bandwidth to talk about the game in a consistent manner before release or to set up external testing opportunities. Furthermore, with such a short development it is understandably hard to show cool content way before the release. This needs to change.
For the next project, we’re trying to get the development and our reaching out effort more interwoven!
Project management and game design issue
For parts of the projects the development was too loose, managed with a mix of excel for the overarching planning and Trello for sprints.
As we explored and research, estimating polishing time and narrowing down tasks became increasingly harder. Also, since I got in the team at the beginning of the project with no time for pre production whatsoever, the game was designed as we went along.
It worked out somehow but we’re making sure our future productions are more closely monitored and organized in sprint and and some preproduction time is correctly allocated. Having at least a tentative design and feature list in place will allow me to split up the project in epics and user stories and distribute those over the course of the allocated production time to make sure we’re not overly ambitious (if you need more explanation about project management methodologies, feel free to ask in the comments!). We also decided to move to an all-in-one tool for keeping track of the project and chose Favro. It’s basically Trello evolved, it’s by no means perfect but up to this point it’s working well (Hack n’ Plan was our second choice but the inability to print out task cards out of the box was a deal breaker).
Also, game design documentation was nonexistent, leading to some decisions being re-discussed. As every developer will tell you (before forgetting it), always write down the very good reason why you scrapped something!
3D asset orientation
Many 3D art assets that we produced were not aligned on the same axis, causing problems when implementing them in Unreal. It’s an issue easily fixed with a proper template but an issue nonetheless that led to some asset integration headaches. Both Maya and 3ds Max have different axis coordinates than Unreal as seen in the example below taken from a A clockwork berry.
All in all, the team is super happy of how the project went. As I said above the project didn't really meet it's sales target but the production itself went smoothly with no crunch. Nonetheless, there are many fine points we can improve upon and except for our way of handling communication, which is more of a structural thing we need to work out, the rest is fairly small stuff.
Hopefully we'll get to release some new content for Mr.Hack Jack: Robot Detective and we'd love to do an Oculus Quest (we haven't been allowed on the platform yet).
We're also working on a new project which will be very different and designed for a core audience. You can follow the development every weekday on Twitch!
Oh and in case you'd like to try out Mr.Hack Jack, check out the Steam page below to buy it or wishlist it <3
Let me know if you have any questions and/or feedback! Thanks!