We at MozgoParty have been doing online quizzes for 3 years now. For us, this is a streamlined process in which we are good. But about a year ago, the company came up with the idea to make a game unlike anything that had been created before. And release her MVP in three months. Yes, we are optimists 😉
As soon as the idea came up, an initiative group immediately appeared to implement it. The team included questioners, an editor, a marketer, a creator from a friendly organization, and an R&D leader. We met once a week, having difficulty finding time and breaking away from our daily duties.
We started by discussing our expectations for the future game and reviewing dozens of references. They played something, looked at reviews of something, discussed a lot and argued a little. So, after several meetings, it was decided that we would make an online detective game with the ability to control through a chatbot.
After a few meetings, we decided on the format of the first detective case – it was supposed to be a murder in the theater. We also decided that the player will need an assistant – a reasonable electronic forensic system, well, or just R.E.K.S.
We started writing the script, coming up with the structure of the game and the mechanics of the tours. There have already been arguments a little stronger, even a couple of times they had debates to find the best solution. Everyone did what they could and wanted. We distributed tasks and at some point began to record the results of the meetings (it’s a pity that not from the very beginning). The main tools at this stage were the board in Miro and several Google docs.
When almost six months of euphoria and creativity had passed, it became more difficult: the idea had to be implemented, the deadlines had long since expired, and our resources were not enough.
The following difficulties became apparent:
the team for the project was assembled from those who took the initiative, but we did not take into account the workload of these people on the main tasks, and, as a result, they could allocate at most a couple of hours a week to work on the project;
we did not know our technical capabilities well and postponed communication with the IT team until later (spoiler: in the end it turned out to be a pretty penny);
we had no project and no documentation, no planning and no roadmaps;
the team consisted of enterprising, creative, cool guys, but they lacked specific skills and experience. For example, we did not have an illustrator, a sound engineer, an animator. No one who could beautifully embody our idea;
didn’t communicate with our users and create the kind of game we wanted to make. Not one that our audience would be willing to buy.
Of course, all this became a series of unforeseen difficulties for us. But a lot of time and effort was spent on the project – it was too late to turn back. Therefore, we made a key decision: we singled out a person who was supposed to deal only with the release of the R.E.K.S. game.
In the next month, the project had a roadmap, a board with tasks in Asana, a deadline, and all that. Urgently resolved issues with the visual component and the crutch-technical implementation of the game.
The game was a series of short videos with introductory videos and history, tips and rules from R.E.K.S., tasks and timers, in parallel with this there was a chat bot assembled on a third-party service in which these tasks had to be completed. The video sequence and the chatbot existed separately from each other. The game was as linear as possible and, with any choice of the player, led to one plot ending of the game.
A month later, MVP saw the light. It was played by employees of the company, their friends and several dozen other players – a total of 100 people, of which about half gave feedback.
After reworking all the feedback, we decided to release three combat episodes of the game in three months. And then they dug in again. Instead of just making a couple of major tweaks that players have been talking about, we’ve redone everything we can get our hands on:
changed the visual concept and design of the game;
hired a narrator and wrote a complex non-linear plot (the first episode had 7 endings);
switched to another service for the chatbot;
set up a connection between the video and the chat bot – the player saw the result of his choice and could make mistakes.
Ultimately, we missed the deadline because we did not take into account the scope of the edits and the lack of a dedicated team. But already working on the second and third episodes, we almost managed to finish everything in a month.
166 people played in the first paid episode, 24 in the second, and 1 in the third. The third episode was the final one, and the R.E.K.S. closed because we never managed to bring the game to the ideal.
As a result, we have invaluable experience, mastered technology with a chat bot, understanding of the weaknesses of internal services and conclusions:
A team is important in any project. To create a browser game like R.E.K.S. the minimum required stack is a product or project, game designer, designer and / or illustrator, motion, sound engineer, programmer;
you need to clearly understand your technical capabilities at the start. If we made the game with what we already have, we would do it faster and cheaper, and in the end we would have fewer bugs;
it is worth communicating more often with the end user – those for whom the product is being created. The better we know and understand it, the more likely it is that the result of the work will bring money;
a new product needs an explanatory team – advertising, announcements, explanations and a search for the target audience are needed, and this will again require resources;
ideas should be quickly implemented, quickly tested on real people, quickly edited and tested again. If you spend a lot of time at the idea stage, this does not guarantee an ideal result: there will always be something that you did not foresee;
testing is everything. If you do not test the game on a large number of real people and do not fix all the bugs, then this large number of people may be disappointed in your product.
Now we have decided to focus on games that are easier to create, that do not require significant modifications in our IT system and that we can quickly release and test. At the same time, we are working on creating a multiplayer for our players, based on experiments with a chatbot.