Path Of The Indie - Part 8/15 - Work During Pandemic
Greetings! For newcomers here is the first post where you can find who I am and why these articles might interest you. Disclaimer: I’m not going to tell you how to make video games but I will share my experience and learning process of managing an indie team while following the path.
How could a young indie team react to the worldwide quarantine? In February 2020 I supposed two different things:
Moving to the remote format with their daytime jobs team members would have more free time to devote to our project.
The confinement blues would devour our team to freeze the project till uncertain times. All would play games to avoid anxiety and sad thoughts, instead of creating them.
The truth, as usual, lied somewhere in between. Well, we have already been working remotely from the very start and learning to work asynchronously. I’ll tell you more about our pipelines and established processes in the 11th post. Now let’s return to the pandemic.
Thanks to our acquired skills to work in such a way, the coming of “total remote” didn’t have a big impact on the project as a result. We still gather online to our weekly team calls, set the tasks in task trackers, collect the info, discuss our progress and keep creating our game as we had been doing before the quarantine.
My first thought about ‘having more free time to devote to the game’ proved to be wrong. I don’t know exactly how this freed time was spent but there was no speeding up in the development. That’s for sure. Everything paces the same as before. The world’s gone mad, everyone has their personal or job related perturbations but we try to keep that apart from our common work. As for us, we didn’t have any changes.
However, universal dismay that started to manifest in many industries has slowly been slipping into our team too. Uncertainty, social isolation, confinement at home - all that are reasons for anxiety to many. At some point, people started to miss conference calls or just disappear for a week without notice. Some admitted honestly: “I’m depressed, leave me alone, please”. Those quitted the project eventually, by the way. Partly with my own initiative. We are not forcing anyone to stay and work without a reward. It became clear that the team’s motivation suffered and we couldn’t afford that. In times like this you have to invent something to keep the morale high. As we were at the step to start looking for investors, it was time to clarify the equity participation in the studio to show the employees “light at the end of the tunnel”. To answer the question: “What will I get in return when our project is released?”
This answer had already been written in our charter but in very vague terms. Something like “the team gets 50% from sales, in the period of 1 month following after the release”. Far from being adequately formulated, this note exists just to be taken in account in future.
So I began to prepare a proposal for the team with the system of options. I counted on raising the motivation if we clarified the terms of this part of the reward.
After a proper research in the open resources and reading articles with public access, I composed a table of criteria where the size of options for each employee correlates to:
Founder or non-founder. Obviously, this is the most significant coefficient.
Personal ambitions. Someone could ask for 80% or “the ring to rule them all”. Sometimes it happens and you both have to make the compromise.
Time devoted to the project. I divided the ‘6-month period’ having a different allocated parameter each. It’s not just a “veteran status” but also a certain indicator of loyalty.
Professional value. The skill level is very important for the final product’s quality, and it’s amplified by “irreplaceability”. If you have only one programmer then he/she has 100% value.
Personal merits. Includes all kinds of situations from “bringing a valuable member to the team” to “creating the whole lore of the game”. Shows the contribution of each person into the project.
I created the share distribution model using these indicators. Keeping in mind, of course, the shares of future investors. I’m not giving the exact coefficients because that can vary for different teams. All you need is a reasonable balance.
I presented this system to the team. With the simple rules for future success scenarios it became more obvious to them why they were working on our game. Now this system is included in our welcome task for all newcomers who have to read and sign the agreement. It exists only in the form of comments in Confluence but it’s already a big step from “verbal agreements”.
Did it boost our morale? Yes, evidently. At least, from about 20 employees in the beginning of the pandemic we grew up to 30 at the end of the summer. 2 out of 3 people left were actually hired by other companies, and only one stayed for the reason of “being really sad”.
Someone could think that an indie team doesn’t need such expansion. They might be right but we have our own path and we’re fine with our numbers. We learned to live with it getting additional benefits. And our motivation system implies that every one who stays with us till the moment we get financed will get a priority to be hired as well as an option in stakes. That will be distributed in accordance with this system. If the future investor wouldn’t like it… well, that’s what negotiation table was invented for.
This part covers the time from February 2020 to July 2020. The moral of the story:
Confinement and remote work is not a big deal for indie. It’s possible for an indie team to work at home. It could be effective enough. The main risk here is the time but it’s not a critical obstacle for young people passionate about creating games.
If you see your team getting sad, try to create a new motivating system or to update an existing one in order to raise morale. And don’t think about “visit a bar together and have a beer”, it has to be something more profound and fundamental.
Funding Our Game: Investors And Publishers. November, 2020
Processes And Pipelines. December, 2020
Teambuilding. December, 2020
Managing The Development Process. December, 2020
Features Of Distributed Work. December, 2020
How To Keep Going. January, 2021.
Path Of The Indie - Part 7/15 - Rebuilding The Prototype
Greetings! For newcomers here is the first post where you can find who I am and why these articles might interest you. Disclaimer: I’m not going to tell you how to make video games but I will share my experience and learning process of managing an indie team while following the path.
In the 5th episode of these series I mentioned the role of our first build in the overall development. Well, it’s safe to say that Rummy Games wouldn’t have existed without it.
Just a short reminder. Back in 2018, the Developer & Founder of our game took a course Management Of Game Projects (increasingly popular in Russia & CIS region) in HSBI. The graduate project was to create your own video game and pitch it to gamedev experts. That’s where the game was born. The very first version was built on Unity. And only he knows what’s happened to it. After graduation he knew that it wasn’t enough so he started to learn blueprints in Unreal Engine having 4 years of experience in Unity.
He spent almost 8 months moving all his work from Unity to Unreal making adjustments and improvements along the way. In February 2019 the prototype powered by Unreal Engine was shown to the Producer who decided to create a study case from it. That’s how our team was created. This was our first step on the Indie’s Path.
We were all fond of the Sci-Fi setting so we started to add the narrative and other features. At a glance it seemed impossible to turn this prototype into a real game right after our first showcase in May 2019. We tried hard to fix the bugs but when one was fixed the other two appeared. When our programmers who had joined us in Summer 2019 looked at all those blueprint spaghetti and sentenced their diagnosis right away: “that’s not going to work at all”. It’s important to understand though that a game prototype doesn’t have to work perfectly or be optimized and completely free of bugs. Not yet aware of it we wanted more than this build could ever provide.
Autumn was coming and new Game events as well. We decided to reanimate our blueprint build - added new colors, a new level and an experimental UI. With all that done we went to the showcase. That build remained with us till December 2019 and we are currently polishing new architecture. The reason was the lack of time and part-time format. It’s not easy to create a new build especially when you have only the “how NOT to” as a reference.
Thanks to our Producer we got invited to one of the podcasts where we could show our old build barely alive. It got even worse by that moment - experiments with inventory made navigation go nuts, some npc and squad members began to run towards zero coordinates. As a result, we received tons of recommendations on “what to fix”. The most relevant was “add the game, pls”. There was no fun in the prototype. And ‘no fun’ means ‘no game’. After the podcast we unanimously decided to abandon that ugly ‘Frankenstein’ and concentrate all our efforts to develop a better version.
In Spring 2020 came the isolation and lots of unmissable game conferences in online format. We used again our “frozen” build. In July we applied for the Unreal Engine Contest where we successfully passed two eliminatory stages to our own surprise. However, getting into finals with our build seemed unlikely. So right before the ending of semi-finals stage we decided again to raise the previous prototype *for the last time*.
There are two main gameplay activities in the game: rescuing missions and preparation for missions a.k.a. Life on Ship. During the last summer we had been completely redesigning the second part of core loop and had implemented it in our build. In addition, we changed the UI, improved visuals, turn-based tactics and temporarily removed non-functional stuff. We promised to ourselves that's the last time we were distracted by the old build.
Even with appealing visuals, two in-game cutscenes, reworked UI, core loop and other minor changes we didn’t get to the finals of the Contest. Audience and judges wanted to see the ‘game’.
As for the new build with no ‘blueprint spaghetti’, we are planning to release it in February 2021. Right now we’re working on a tile movement system, certain mechanics (i.e. deep interaction with HNPC like healing/escorting/covering from fire), lighting, color, VFX effects and other features. Before implementing a new mechanic we prototype it using blueprints, test them in the present build and then make a clean copy in C++.
This part covers the time from February 2019 to October 2020. The moral of the story:
In our case it took one prototype to assemble a team around it, participate in dozens of game events and competitions, create game documentation, announce the game on Steam. That build moved us really forward on the way to MVP. A high-quality build is your best friend in development and promotion when you don’t have financial support. It’s better to have a build as soon as possible and keep it updated regularly.
Prototype doesn’t have to be perfect - it just has to be.
Build can be used in the release version of your game for testing different mechanics and features. It’s easier to remake into a clean copy than write code from scratch.
Funding Our Game: Investors And Publishers. November, 2020
Processes And Pipelines. December, 2020
Teambuilding. December, 2020
Managing The Development Process. December, 2020
Features Of Distributed Work. December, 2020
How To Keep Going. January, 2021.
Path Of The Indie. Part 6/15. New Acquaintances
Greetings! For newcomers here is the first post where you can find who I am and why these articles might interest you. Disclaimer: I’m not going to tell you how to make video games but I will share my experience and learning process of managing an indie team while following the path.
As soon as I started to show interest in promotion of the project, I got overwhelmed by hints and tips about networking. I heard from every corner: “Make new acquaintances! Go get to know other people! Broaden your circle of connections!” and everything. Alright, alright! Sooner or later I’d got down to this part.
When we were a small team of 5, that was a job of the Producer. While others were more concentrated on working on the game rather than looking for new contacts that might be useful.
It’s hard to pinpoint when we began to treat this more consciously. I’ve been writing articles on DTF for a pretty long time, our PM is like a Recruiter and does the headhunting, marketing managers work with communication channels and those who get in touch with us. There are a lot of opportunities. I’m going to tell you about those which turned out to be most effective and are used on a regular basis.
And again, game events. Like it or not, they are created for networking. As soon as the marketing manager applies for participation in a game conference he gets in contact with the organizers: he communicates with them, asks questions, provides additional information about the project on request, etc. What’s for?
Organizers of different gamedev events are the first frontier to pass for useful advice and development direction, contacts and constructive feedback, possible bonuses and an eye-catching booth.
This job works best for responsible and sociable people. If you are an indie-samurai and do everything that means you will sacrifice your development time. But working on the build has to be always your priority.
Events of such format give you an opportunity to approach anyone and have a conversation about video games, what you like to play and your projects. It’s as simple as that. This is how we met Happy Fox Studios who are helping us to design the UI.
There’s much work at the booth. We usually split our team into 2 groups - one welcomes visitors and showcases the game and team itself while the other goes for event activities and networking. After a while we rotate. If you’re alone then you risk to spend the whole day sitting at your booth because you can’t go and listen to speakers or check the competitors’ projects.
Apart from offline public events there are various digital opportunities such as contests, grants, forums, social networks, blogs and many others.
Some time ago we came to the conclusion that it would not be fair to load all the communication on marketing managers. In our indie reality you have at best a couple hours per day to commit yourself to your project so it’s impossible to track all the channels, send emails and submit for planned events. You also have other work to do - developing the product, preparing the content for publications and publishing it. It may take up to an hour to publish a single article/devlog/update due to formatting and moderation. That’s why we decided to share the platforms between our team members.
Website and Medium are under control of our Marketing Lead
Our Community Manager works with the Steam page and Twitter
DTF is on me. This source is popular within the RU-part of the Internet and similar to Reddit.
Everyone creates content (articles, screenshots, videos) beside communicating with the followers thus representing our team and expanding the information flow of the project.
At the same time we look for the games similar to ours and contact their publishers directly. We pitch our project to them and answer their questions providing additional details - game design documents and playable build. So we present our game and get new contacts at the same time. Right now we are working on the “before - after” presentation to show the progress for the last 6 months.
We participate in possible competitions and public pitches like Unreal Engine Development Contest, GD Bay, Keep Calm Do Games and others. Such a proactive attitude might bring you people from other companies you won’t expect. UEDC-2020 was extremely rewarding so Xsolla provided us with their site builder as well as ByteDance is considering to be our publisher. That is one of the reasons why we chose Unreal Engine as the Game Engine I have been asked for a long time.
Last but not the least, each team member brings his own network power when joining us. Our Producer plays the most important role in it providing as many resources as possible. He put us in touch with MGVC. They gave valuable advice about presentation documents. Also, my friends from Talerock Studio got the key art for our project which we’ll demonstrate very soon.
But the coin has two sides. I mean our reputation leaked out to other studios hunting for new employees. Our former 3D-animator works in a newly created studio ‘Black Caviar Games’. They noticed his work in our project and proposed him a job offer. Nevertheless, we have the basic set of animation which is still enough for current work. We do not exclude the possibility of future collaboration with him either. Actually, it’s a good sign because the team and the project grow thereby in the public eyes.
This part covers the time from April 2019 to October 2020. So why networking is important:
There are many ways leading to the peak of Fuji. One of your contacts could be your lucky ticket there. Another could bring unexpected benefits. You never know so don’t miss a chance!
This story is about a team not your own. Sharing the burden of networking with your colleagues prevents you from burnout and helps to keep some personal time. It’s impossible to be in several places simultaneously (unless you have a few clones at your disposal).
It’s also amazing when you see people synergizing while being together and having common interests. You get inspired by their belief in the success of the project. Motivation is hugely important for small indie teams where money couldn’t be the option. And our case is not an exception.
I’m grateful to all those who worked on our project before and who are in the team of Rummy Games now. We’re in this together!
Funding Our Game: Investors And Publishers. November, 2020
Processes And Pipelines. December, 2020
Teambuilding. December, 2020
Managing The Development Process. December, 2020
Features Of Distributed Work. December, 2020
How To Keep Going. January, 2021.
Devlog #15
Greetings! This is Rummy Games with the new 15th dev diary. This time we are sharing the interview with our sound designer — Ruslan Takhaveyev. He is going to tell us how he joined the team and his work with sounds and noises of one of the main characters — Harren the Defender.
Ruslan, tell us a little about yourself
I became a part of Rummy Games in September 2020 after passing the interview and an assessment test. I haven’t worked in gamedev before but I’ve been studying FMOD+Unity and Wwise+Unity for a long time. I have solid experience in sound design and creating music for videos. Recently I’ve started exploring Unreal Engine and luckily Saturated Outer Space is powered by this technology. That’s wonderful!
What was the assessment test?
I was asked to create sounds for the game hub, they call it “Life on Ship”. It is a spacecraft carrying the squad. To be more straight, it was to record background sounds for the bar, the main bridge and the captain’s cabin. However, real tasks in the project proved to be much more interesting. And difficult, by the way. I work on sounds related to the game's characters and this job requires knowledge of the lore of each one, their created 3D models, their description and nature.
What tools do you use in your job?
We're working with FMOD as middleware. Its interface is similar to DAW so it allows me to create the sounds from “the box” - it speeds up the whole process. I also use Reaper for additional processing or recording. Some sounds I search in ‘freesound.org’ then make a few tweaks. Others are taken from my royalty free library which is pretty big.
How does the development process flow?
As mentioned before, I need to keep in mind the characters’ bios and lore. Visual indications must also be taken into account when generating sounds such as moving, taking damage or dying. For example, Harren is a robot who was a human in the past. He faked his death by totally destroying his physical body and putting his digitized mind into a steel shell of a robot. (That’s insane!) So, I knew that his sounds must convey his human nature in some way like his voice cannot be completely devoid of emotions. Harren’s prototype:
Harren
Harren comparing to other characters (second from the right)
So we have: Harren is no longer a human, he is a full metal cyborg. Which means that the sounds from him should indicate his big weight and might with the hints of his human origin. As a reference I used the character animation:
Further work consists of following steps: prepare the most suitable sounds (if needed) edit them with FMOD effects (“pitch shift” and equalize is used mostly) place on timeline and synchronize them with movement according to the animation put additional sound layers for every “tact” of movement to make it more complex and deep.
Robot is not just a toy, there are a lot of mechanisms involved so even one wave of a hand provokes more than one simple sound. We can hear several sound layers at the same time. Even if one of them is removed you would definitely feel the complete difference. In addition, every track is slightly randomised in “pitch” and “offset” parameters to sound less repetitious.
Adding layers (by preference):
Randomizer (on the right):
What are the current results?
Steps – https://youtu.be/vu8BTwtvg40 Taking damage / hit - https://youtu.be/KbEtHkXTjr8 Shield clashing – https://youtu.be/plnrdQFMfIg Death – https://youtu.be/KI8AwWTcygs
It’s only a small part of what needs to be done with this unit. But there are dozens of them in the game!
What are you doing next?
After importing the sounds into the game and conducting additional tests it might require some ‘fine tuning’. Then I will put my hand to create primary sounds for other characters which need to be done for the vertical slice.
Path Of The Indie. Part 5/15 - Our Second Game Conference
Greetings! For newcomers here is the first post where you can find who I am and why these articles might interest you. Disclaimer: I’m not going to tell you how to make video games but I will share my experience and learning process of managing an indie team while following the path.
After DevGamm 2019 we didn’t give much thought about our next possible game events. We only started to rebuild from scratch and the old one was left behind but for a short time. I will tell more about its role later.
Anyway, we had quite a particular goal — finish refactoring the code in 2-3 months and show a renewed build based on new architecture. However, that was incommensurable. By the Fall 2019 - the season of industry events, exhibitions, conferences and meetings - our forthcoming build hadn’t been going to arrive any soon. Considering its production speed we decided to proceed with two different versions simultaneously. Developers were supposed to work on the new build version (by 2 devs) as well as the old one was to be remade by its author with help of the rest of the team (8 people) and was subject to tests of level-design features. We chose the GameDev House event as an opportunity to show our progress.
The event proved to be very useful for us. Firstly, we received a lot of feedback just like on the first conference. Secondly, there was a competition among the projects with visitors giving their votes during the showcase. We drummed up as many people as we could to our booth and asked for their likes. It seemed that all our efforts brought us a free ticket to White Nights and the Audience Choice Award which decorates our Steam page. Moreover, we caught the attention of some people including our coolest Level-designer (Environment) we’ve ever met and an ex-Marketing Manager who was eager to try himself in gamedev.
We were shocked by the invitation to WN. Of course, it was an opportunity we couldn’t miss. Luck smiles at those who are ready for it, remember? That’s how our second conference turned into two events at once. However, we got a kind of Mexican standoff - four suitors interested in the event and only one ticket. We resolved this situation by buying three additional tickets and splitting their cost between four of us. The free ticket became some sort of discount.
WN was less than a month away from GDH but we wouldn’t have gained much from showing the same build we’d already tested. Here was the time when our recently recruited Level-designer proved himself. As it often happens with new blood he was ready to move mountains and that’s what he actually did! Not only did he construct a test level from sketches but also filled it with objects, made a showreel with renewed visuals ready for release on WN. The ex-Marketing Manager helped us to make a rack with the game’s logo and print flyers which are still in use nowadays.
After applying to the conference we got our booth with UE promo. Was it luck or a coincidence or the impact of the showreel demo - never guess!
We count White Night Conference 2019 as one of our most productive events!
We met UE representatives and made an agreement to support us with technical questions related to the engine
Nvidia representatives gave us a video card for tests
A few art studios and freelancers offered to outsource a part of content production
Six publishers invited us to collaborate as soon as we get MVP
We spoke with other indie developers and got impressed by their projects and development approaches
Finally, we found an inspiration and an occasion to start our Devlogs!
This part covers the time from August 2019 to October 2019. The reasons to visit game conferences even if you don’t have a finished product:
You make a lot of useful acquaintances, broaden your network of contacts and discover new possibilities.
On showcases you should pursue appealing rather than functionality.
There is always a chance to win a prize and get promoted to attend other events.
Funding Our Game: Investors And Publishers. November, 2020
Processes And Pipelines. December, 2020
Teambuilding. December, 2020
Managing The Development Process. December, 2020
Features Of Distributed Work. December, 2020
How To Keep Going. January, 2021.
Path Of The Indie. Part 4/15 - Recruitment
Greetings! For newcomers here is the first post where you can find who I am and why these articles might interest you. Disclaimer: I’m not going to tell you how to make video games but I will share my experience and learning process of managing an indie team while following the path.
In the previous article I partially mentioned how we scouted for new people and expanded our team. Now I’d like to shed more light on hiring and adaptation processes, assigning responsibilities and features of “voluntary development” discovered.
To remind once again, I describe my own experience gained in the actual project. I used to hire personnel for the companies I was working for but S.O.S. is quite a different story. We all work very hard with enthusiasm and without a reward (yet). That’s why you need an unusual approach to keep high morale. Let me show how our team of enthusiasts works.
Hiring
Hiring and firing people is like ‘sex’. Everyone knows what it is theoretically but it takes lots of practice to understand how it really works. A piece of advice to those who consider hiring employees: start as soon as you feel a need for them. Keep in mind:
First screening criteria for scouting
The advantages for a potential candidate to work with you as well as short and long-term bonuses
Differentiation from other indie studios
Assessment test for a candidate
Determination of responsibilities
Process of onboarding
But hiring is only half of the work. You have to get to “fire” someone sooner or later. First point will be corrected with every person you dismiss. Your first interviews will become more informative after you shuffle off a few (or lots of) people.
After passing 3-4 times the circle of “hire and fire” you will be able to set the primary onboarding. The goal here is to minimize your efforts and time needed to integrate an employee. Try to automate this process as much as possible.
Usually, at the first meeting we discuss following topics:
The motivation. Why does the particular candidate want to join the gamedev industry? If the answer is simple: “I just want to try” - then it would be better to end the meeting at this point. Probably, that person would be disappointed after several attempts because the gamedev does not live according to their expectations.
Playing video games. Those applicants who do NOT play at least twice a week would definitely drop off without completing a test. I also recommend not to waste your time on non-gamers even though they can suit the requirements. Obviously, this person will not understand the fun of creating the video game without having fun playing games.
Participating in other projects. If the candidate is currently in another indie team apart from the daytime job, has a dog, starts a new online course, loves car racing, draws in free time, is a proactive volunteer and it will take him only one step to achieve happiness (after joining your team, of course) then it will be better for you to look for another one. Because he (or she) won’t spare enough time for the project. The golden mean would sound like: “I have a job but want to achieve my dream of development of my own game within my free time. I’m available for 10-20 hours per week”. So spend some time studying how busy the candidate is before taking him/her on board.
Experience. The professionals capable of developing the complete game on their own are not known to work for free. It is also clear that volunteers not capable of anything would not make a good asset for your team. We look for people with some basic knowledge in one of the fields (level-design, programming, animation, etc.). So, this is the case when all those online courses certificates come in handy. They won’t matter much when applying for the actual job but for an indie team that makes a huge difference. It is great if the candidate tried to create something before and has a portfolio.
The level of enthusiasm. It’s hard to evaluate. It could be your feelings during the interview or just a subjective perception that partly completes the portrait of the candidate. It is useful when you are in doubt to hire someone but it can't be the bottom line of your decision.
Following the above principles assures you will get a right member for your team in most cases.
The next step is an assessment test. I would say to give something that could be useful for the project, that could test motivation, initiative, engagement and the level of independence of a candidate. If he/she tries to find the answers on his own - great, you'll get along with each other. If he asks for guidance on every step then move forward as this person is time-consuming. You need someone who generates solutions even if they might be improper in the beginning. It’s crucial to be initiative and eager to learn and follow the path of the indie.
Onboarding
By some point there will be a lot of people gathered working with the piles of stuff. When you feel at some point that you have no time for managing the product it means you are well over that point and in need of a Project Manager who will deal with onboarding and minor workflow processes.
For me it happened when our team reached 14 members. I couldn’t do everything: the product management, guiding newcomers, controlling over the build development, game design process, marketing and other things demanded my attention. It was When our producer brought a PM into our team who handled the setting of the onboarding process with the ‘welcome task’ on our task tracker, created a HR folder in Confluence and many other essential things in 6 months. Thanks to him we grew up to 30 members by spring 2020.
The last thing is a memorable lifehack for indies: people work better in pairs. We figured that out empirically. It’s very hard to work alone. When you have a partner it makes less punishing and more fun when following the indie path. You are more engaged in the development process achieving results faster while gaining experience and earning level-ups. In our case it’s much easier to exchange ideas, opinions, knowledge and utilize technology of the production pipeline.
This part covers the time from April 2019 to June 2020. The moral of the story:
Create and customize the procedures of integrating and dismissal before expanding your team.
When reaching the threshold of 10 members start searching for an assistant with cross functional responsibilities including the interaction with the team, administration and HR.
Trust your people and delegate tasks. You can’t do everything by yourself.
Maintain a healthy and effective working climate. You make your project together so support and respect each other. If someone requests a short vacation - grant it. It will do you good in the long run.
Keep an eye on your team. No one should be left alone with his task and thoughts about the project. Try to focus on the project’s vision and revise it constantly. Otherwise, you risk to end up with developing completely different games.
Atmosphere of mutual respect, basic order in business processes will give your team the primary sense of working on the common thing that might transform into something big and exciting. I believe this is one of the pillars of intangible incentive.
Funding Our Game: Investors And Publishers. November, 2020
Processes And Pipelines. December, 2020
Teambuilding. December, 2020
Managing The Development Process. December, 2020
Features Of Distributed Work. December, 2020
How To Keep Going. January, 2021.
Path of the Indie. Part 3/15 - Unfolding the Development
Greetings! For newcomers here is the first post where you can find who I am and why these articles might interest you. Disclaimer: I’m not going to tell you how to make video games but I will share my experience and learning process of managing an indie team while following the path.
What was horrible? How was it supposed to be changed?
What was absent? How to implement it?
What was worth keeping due to its potential?
What could be cut off painlessly?
To answer all those questions we had in our arsenal the list of reviews from the DevGamm conference and, of course, the roadmap. Back then we had two versions of it at our disposal: the real one for internal use and the fake attractive one for public presentations.
We decided to do some serious feature-cutting and remove at least half of the content. While lacking expertise in important remaining aspects, we began the quest to acquire some in 3D-modeling, code writing, animation and marketing.
We used such resources like:
Freelance platforms, forums and job sites
Asked our mentor from the educational program to look through students
Searched among our friends and contacts
As a result, we managed to get onboard two experienced Programmers, a novice 3D-modeler, a Marketing Specialist, and found by a fluke a Level Designer and Game Designer with proficiency in localization in English and Chinese. It took us 2 months, dozens emails sent to friends and acquaintances, a few announcements made on gamedev forums and the networking power of our mentor.
Was it difficult to scout? I would say ‘no’ but it did require a lot of patience and clearly specified responsibilities awaiting for ‘fresh blood’.
Was it difficult to get through responses? No but we weren’t overwhelmed with applications, of course.
Did it become harder in managing the team that grew up twice its size? To some degree. We created a few subject-related chats in telegram which I took under my moderation as a PM. One for different kinds of announcements and general talk, a marketing themed chat and a chat dedicated to content, art and music. We set two conference calls per week. I prepared agendas for each, wrote down the results, created tasks in Jira, filled up the data in Confluence, saved documents on shared Google Drive and sorted all up to make the workflow easier for each member.
In July 2019 newly joined developers analyzed the insides of the project and reported back with a disturbing sentence “we need code refactoring” which stood for rebuilding the architecture and moving from Blueprints to C++. We had no choice and put that in action.
We carried out SWOT analysis and established that our game would be story-driven and all the mechanics and the visuals designed around the narrative. However, we still needed to determine the core loop gameplay because, mildly speaking, using “profound lore” is not quite an original approach. We began to create levels and game design drafts. The concept was revised and became more detailed. It was still far from actual documentation but we caught the essence.
By that time, we established unspoken rules which I suppose made us act like a dream team. These followed by the series of administrative documents: our charter, company policy and the list of employees. Our obligatory ‘welcome task’ includes a first insight into these guidelines.
Tasks for the team were based on a working version of the feature list which appeared to be efficient as it facilitated planning conference calls, marketing activity and made the overall workflow more transparent.
Our project was growing to something bigger although it had been conceived for learning and practicing at the very beginning. All members of our team as of the end of the summer in 2019 were aware that the development process would take much longer than it had been planned. To recap, we aimed to release the game (at least in Early Access) in August 2019 within 7 months of work. We had loads of enthusiasm but few free time in the evenings. The prolonged period for development wasn’t frightening to us. It is not the first time in gamedev history...
At that moment the founders came up with the idea to transform this “gathering in a garage” into something serious that could actually sell itself. We all agreed to create a real thing as an objective. Not something to mention in the portfolio but to be our springboard for becoming a real developer studio.
This part covers the time from June to August 2019. The moral of the story: the project was being developed as a product as well as our team had improvements in infrastructural and organizational perspective which allowed us to gain new levels afterwards. It took us certain steps to leave the unknown and enter a new stage of the indie path. Those steps were:
Testing the build and key feature of the game during the conference showcase
Accepting that almost everything was terrible and had to be remade
Identifying how good the idea worked on attracting new people to work with us
Applying principles of interaction between team members which have minimum administrative costs
Converting our dreams into something feasible and venturing forth to the goal of making them true. So, we decided to start our own studio.
Funding Our Game: Investors And Publishers. November, 2020
Processes And Pipelines. December, 2020
Teambuilding. December, 2020
Managing The Development Process. December, 2020
Features Of Distributed Work. December, 2020
How To Keep Going. January, 2021.
Path of the Indie — Our First Game Conference Part 2/15
Who am I and why these articles might interest you? Here is the first post of my story.
Disclaimer: I’m not going to tell you how to make video games but how I did experiments, what I learned from them, and my future approaches to management of an indie team while following the path.
***
There is only one way to eat an elephant: a bite at a time. Our next bite after announcing the game on Steam was participation in DevGamm 2019 in Moscow. We have been fueled with energy and inspiration for more than two months. On the one hand, the registration process is very easy as you can find hundreds of preparation guides for such events including tips like to pick up deodorant and peppermint candies with you. On the other hand, it is much more complicated from the point of the developer’s view. Though we had some real work to be done. We began to prepare in advance for 2 months before the event. Our development plan consisted of several tasks:
Fix the most critical bugs
Choose a demo-level (5 of them were up and ready to go)
Fill that level with as many interesting gameplay mechanics as possible
Record the main music theme and general sound effects
We also discussed between us to determine:
Who will be the speaker of our team;
Who will be responsible for the stuff like business cards, booth and communication;
The schedule to be around the stand. It was synchronized with our personal meetings.
Guess what we missed? The presentation! Everything was thought out besides this important thing. We had absolutely no idea how to pitch our game to visitors.
The Failure
Two weeks before the event they published the list of projects at the showcase but we were not in it. Our prototype was way too raw and didn’t make it through. All our efforts proved to be in vain. Although we could still go further and spread the word about the game. The only thing was to figure out how to. We made a gameplay video, downloaded it on our phones and prepared a pitch based on the project’s comparison to similar popular games. To that moment we had yet a simple analysis of Target Audience at our disposal that can not be said about the pitch which lacked USP description as it had only the prototype and not the concept. In general, we were ready to rush into the conference without any official presence in order to gather at least some feedback.
The Miracle
One of the facilitators contacted me the day before the event and asked if we still wanted to present our game. One of the projects happened to withdraw so there was a vacant slot. At the same time we had nothing ready - no laptop to display the game, no presentation, only a bugged build! We couldn’t let us miss this opportunity to test our prototype and ourselves. This news made our team experience joy and terror both transformed into furious action to have everything done during only one day.
What we learned due to that conference:
Preparation for the first conference is invaluable to practice your organization skills. It clears your head and makes the game’s concept more pronounced.
You get to know your team. Who is reliable no matter what and who is not ready to suffer for the sake of the project.
You have to show your build to the audience to gather reviews and collect useful data. The best way is to watch them playing your build.
You can make acquaintances with industry experts and local celebrities and ask for their thoughts and advice. Thus, our booth was visited by tinyBuild producers and renowned GameDev gurus from Russia like Sergey Gimelreykh and Michael Kuzmin. Their insight was much appreciated.
Don’t miss a chance to dive into the game dev world and meet other indie enthusiasts with shining eyes, eager to create their own chef d'oeuvres. In addition, you will become aware of the full potential of your project.
This part covers the time from March to May 2019.
The moral of the story: show your build to the gaming community as early as possible. We received a ton of comments and, what’s more importantly, understood the flaws of our prototype. The feedback we gathered helped us to see the full picture with less emotional bias. Of course, others might play your game with preconception and be emotional in their judgments but pay more attention to their playing behavior rather than words. What do we do next?— That’s hard to say. More is coming in the next articles.
Who am I — CEO and Co-founder of the Saturated Outer Space video game.
I’d like to share:
My experience and concerns about starting and developing a video game.
My belief when creating and developing your game you definitely need a team of driven likeminded people with passion for video games and ready to work hard and learn hard. You might think that there would be plenty of rewards but the path is still not over yet. So we will talk about it later.
How this text might be useful? This is an honest story of the path of the indie team with some plot twists. So if you are indie yourself or do some thinking about joining the game dev industry or just wondering how people create fascinating worlds from scratch I believe this case is worth a look.
Disclaimer: I’m not going to tell you how to make video games but how I did experiments, what I learned from them, and my future approaches to management of an indie team while following the path.
It all began in late February 2019. At that time I was eager to get into gamedev but with no luck. So I even wrote an article about my fruitless attempts and soon after I was introduced to the Director of educational program in Russia "Management of Game Projects" who assembled a “Rummy Games” team as a Mentor by the time of the first conference call. They invited me as well as I was looking for an internship in a game project.
Of course, some of you would say that it’s possible to start solo. I completely agree with them but when you have got experience in AAA-projects and looking for some fresh air. Or a genius-introvert. Or you found yourself locked in the basement for 4 years with enough food supply, laptop with up-to-date game engines, access to electricity and no internet to distract you. (Un)fortunately, not in my case.
My basic premise so far is that being with no team behind your back is like being trapped in your own fictional world with unstoppable crunches and 0% of fun. Let me show what I mean by my series of stories.
There were four of us from the start: Game designer, Narrative designer, Developer (plus technical design), Marketing Analyst (me). All of us had some sufficient background before but only Vlad was qualified to compile a working prototype which he had been making for the last 8 months in Blueprints of UE4 and had been looking for brothers in arm to proceed further.
Our Mentor guided us in creating the Steam page of the game and helped to set up first milestones at the very beginning.
The idea was to finish the game as soon as possible. First, to announce the game on Steam (in March 2019), and make up channels for promotion. Also, work hard after getting home from daytime jobs, force all decisions and prepare a playable build from the prototype in 6 months. Then, release in August 2019. As a result, get a sweet case in the portfolio for our CVs and move further. Everything is covered up.
According to our plan I started the competitors’ analysis and target audience research keeping in mind how the game should look on release. Rest began to write the plot, develop the mechanics and transform the prototype into the game.
After 3 conference calls it became clear for us that we needed to bring some order into our chaotic activity. So I took responsibilities of a Project Manager: arrange and hold call-meetings with agendas and follow-ups in Google docs, track team's commitments and other common issues.
Google docs is not suitable for such purposes so we decided to move to Jira and Confluence. Apart from the task management we also had to organize documentation of the project. These also fell into my hands as I had experience with task trackers and managing teams with dozens of people. Even though my expertise comes from a completely different sphere, business philosophy is quite familiar and people are people. If you respect your colleagues, take care of your team and do your best then congratulations you are a decent PM.
As soon as we established our workflow we found a Sound designer who composed fabulous tracks for the game. He is a real catch, that's for sure! Unfortunately, due to some reasons unrelated to our project our Game designer left the project by that time. So the Narrative designer assumed responsibilities in Game design.
That is how the story started. It covers the time from February to April 2019.
The moral of the story: it’s easier to start as a group if you choose the path of an indie-samurai. Gather into parties, cooperate with people who are on the same wave as you and have common views. Join existing teams, share your knowledge and bring new insights.
Funding Our Game: Investors And Publishers. November, 2020
Processes And Pipelines. December, 2020
Teambuilding. December, 2020
Managing The Development Process. December, 2020
Features Of Distributed Work. December, 2020
How To Keep Going. January, 2021.
Devlog #14
Hi everyone! This is us again, that is the Rummy Games team, and this is our 14th diary. We continue to share the details of the development of Saturated Outer Space. This time we will share an interview with Anastasia Medvedeva, our VFX-artist. She will tell you in detail about the creation of a model of one of the enemies: The Swarm.
Anastasia, tell us a little about yourself.
I got into the project a few months ago thanks to my teacher. He introduced me to the team and helped a little with the implementation of the first technical task. At that time, I had only been studying Unreal Engine for 2 months (before that I worked with Unity, Houdini and Cinema 4d). However, my knowledge was enough to complete the introductory test and join the project pretty quickly.
What were your tasks?
The main task was to create one of the units - the Swarm, consisting of nanorobots, many micromachines capable of floating in the air. It will have to interfere with the player during the game to complete various missions. The Swarm has many animations: moving in place, moving from cell to cell, physical attack, electric discharge attack, dodging, taking damage, death, and others. The robot itself must have blades, paws for gripping or moving, and antennas. And also it has to look like a virus.
References:
What tools were used in the development process?
The robot itself was modeled in Maya. And the Swarm was made with the Niagara plugin. Niagara has the advantage of being able to exchange particle data without the need for coding. This helps users create their own behaviors instead of requiring code intervention to create new, strictly-coded functions.
In a conventional particle system, their modeling is controlled by strictly programmed modules, each of which provides a specific set of functions for changing the particle attributes. In other words, Niagara provides more possibilities for imagination, practically does not restrict the user and creates a single effect within one system.
Niagara also surpasses the regular system in performance, it has a friendlier interface that is similar to the particle system in Unity.
How did the development process go?
Initially, I did not know that the Swarm robots should have blades, so I thought that it must be a mechanized insect such as a wasp or a fly.
Therefore, the first model looked like this:
Further, before starting the work, I looked at a bunch of tutorials on Niagara, since I had never worked with it before.
The first animation I started was a flight animation. It consists of the two parts: the robots themselves and the particles which these robots follow, imitating wave-like movements. To do this, you have to "tell" the particles to attract each other.
The animations of movement, hitting with blades and dodging have a similar structure and are also based on the attraction of particles to each other.
Electric discharge attack and death have a more complex structure: in addition to the robots and their "attractors", there are flashes from the so-called sprites and the lighting effects to illuminate the surrounding space. When attacking with the electric discharge, the Swarm gathers into a "cloud", inside which a charge is formed. When the swarm dies, the robots, shrinking and burning out, quickly collapse into a heap, an explosion occurs, and their remains fall to the ground.
The death animation had a lot of options: additional rays before the explosion, an explosion with fragments of robots, various options for colors and shapes of flashes.
In the end, I can say that Swarm's death became my favorite animation.
What are the development results?
As a final result, we have the following robot model:
All the ready-made animations that can already be imported into the project.
What will you do next?
Further in the plans are the effects of the environment (fire, smoke, gas), shooting, destruction.
