While developing Saturated Outer Space we are very passionate about making its storyline and narrative design positioning them as the main key features.
Recently, we have taken part in "Narrative in Games" online conference hosted by Higher School of Business Informatics the postgraduate business school of The National Research University Higher School of Economics (Russia) in cooperation with the Union of Writers of the Russian Federation on the WN Hub platform, with the support of White Nights, Zavod Games, 1518 Studios, MYTONA and Belka Games.
Within the conference there was held a special competition of narrative design and scenario content in games. More than 50 game titles participated in a showcase sent from indie studios and standalone developers! The jury selected only 12 in their short-list.
Saturated Outer Space won the "Best Scenario of Debut Game" nomination in finals. Thanks to big efforts of our Lead Game+Narrative Designer with just a little help from the rest of thew team.
This award means that we are moving in the right direction striving to give players a unique game experience. Experience that is pleasant to share with others after playing a turn-based strategy. After all, bugs can be fixed, balance can be adjusted, content can be added. But new narrative mechanics are not able to completely replace the negative perception of the game.
Awards presentation (from left to right):
Viacheslav Utochkin - Director of the educational programm "Game project Management" at the Higher School of Economics;
Andrew Mitchell- Broadcaster of the online conference "Narrative in Games";
Egor Ershov - Marketing Lead at Rummy Games Studio.
Rummy Games team is very grateful to organizers, speakers, partners and jury members for the great opportunity to participate in the competition and evaluating our game.
Devlog #18 | Narrative. Creation of the dialogue system.
Good day everyone, dear readers! The Rummy Games team is here to welcome you to the new Dev Diary.
Today our narrative designer, Julia Korn, is in touch with us, and she will tell us about her experience in our team.
About myself
My name is Julia, in the team I work as Junior Narrative Designer and am responsible for the general scenario and details of the game world: creating and developing a storyline for each character and his/her background, the events and their denouements, writing the game texts. I like to create fascinating stories, work on the plot, structure and principles by which the lore of the game is revealed, giving the “voice” to each character, creating the gaming experience which will be interesting for the players.
Some time ago I studied the course of "Game Development": game design, programming and marketing. That helped to form and consolidate the entire accumulated base, all my past life and professional experience.
In the past I am a writer, I have two published fiction books. I wrote in different genres: there were short fantasy stories, a detective story, and philosophical stories about self-development and the search for oneself.
Since my childhood, I have read a lot of books, most of them were about fantastic adventures. Perhaps it played the role in my choice: I did not hesitate at all when I was offered to join the project. From that moment on, my commitment to the game ideas and my interest not only did not subside, but, on the contrary, became even stronger.
About the tasks
The last major challenge was creation of the dialogue system in the game. The first part is writing plot dialogues that will show the stories of the main characters, set the tone for their personality and make them closer to the player.
Since in our game the emphasis is on the plot, it is necessary to reveal the “soul” of each character, correctly present the content, allow the player to plunge into the game atmosphere and provide a choice - to love the characters, or to hate them.
Difficulties in the process
We faced the fact that it was necessary to create a convenient, understandable text and the dialogue system from scratch, on the basis of which it would be possible to string together the logic of behavior and statements of characters, and we had to act guided only by our literary experience and logic. It is always difficult to start, to understand what pieces are needed to get the result in the form of a finished picture.
In order to understand for ourselves how the cause-and-effect relationships of the characters' communication are built, we had to do some preliminary work:
1) To check if we possess all the information about the characters, namely: their stories before joining the S.O.S. squad, the reasons why they came to the service, development in the game process and a possible denouement for each of them at the end of the game. The story of each member of the squad is written in separate documents, with a general description from the 3rd person and the captain's notes.
2) To determine the relationship between the main characters. To achieve this, I made the diagrams, each of which had a general structure and reflected the relationship between the members of the squad.
3) To think over triggers at the levels that will start the conversation and reactions of the characters (1-2 words, or a short phrase).
4) To define the personality of the characters, the features of their speech behavior.
I was asking myself where to get the information about how the elements of speech are interconnected and how they can affect the perception of the character by others. Personal experience of communicating with a variety of people, observing the characters of various movies and books helped me a lot. Among the few listed features are:
Speech defects: the presence of various defects such as stuttering, mispronunciation of certain sounds and their degree;
Volume of statements: the habit of speaking in short and simple, or very long and elaborate phrases;
Richness and imagery, emotionality: will the character use jargon, or will his/her speech be full of parasitic words?
To create the right impression is a rather painstaking work that requires the ability to first look at the character from the "outer" side, and then get into character and try on different speech "masks".
Work Tools
To work with the narrative part of the game, we (myself and Senior Game Designer) use tools such as:
Confluence for organizing and structuring the material.
Miro Board for making the clarity of systems: the structure of the game world and the Universe, the relationship between the characters, the timeline.
Google Docs and Excel for writing, editing and storing the large texts and dialogues.
Results and plans for the future
At the moment, most of the plot dialogues are written with noting the triggers and reactions.
The next step will be the work on the second part of this big task: to think over the templates of dialogues for non-plot communication - short phrases that accompany this or that action; to break ready-made dialogues into smaller parts, to arrange the triggers on the level and test how they will fit into the overall course of the game, how they will be woven into the gameplay, and diluted with the non-plot dialogues.
Path Of The Indie Part - 14/15 - Features Of Distributed Work
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.
Well, this is the post where I reflect on the remote work format and it’s features for an indie team. Why do we have a distributed team, how it all started, what are the benefits and the downsides? Those who have already read the book “Remote” from the creators of “Basecamp” could most certainly notice that I repeat some lines from there. But I read it in August 2020 so the first 1,5 years we were building our remote by ourselves. Sometimes our own experience led us to the same conclusions recommended by “Remote”.
And yes, we started a year before the pandemic so there were almost no trends for remote work back then.
So, why did we choose the remote?
E — Economy
This is the first that comes to mind. At the beginning we reviewed our resources. It was a classic situation: we had no money but had to do something. Nobody except our producer wanted to spend their own money. And he wasn’t ready to get so much involved as to rent an office. With no space we decided to cooperate online using Discord, Telegram, Jira, Confluence, Miro and other free instruments.
We actually tried to use any opportunity to save money as long as it didn’t affect the team’s communication. No office, no transport expenses. Economy is in everything!
G — Geography
Indie teams often gather by the principle of proximity. Many people want to work with someone close and known to them, with whom they feel comfortable.
We were situated not just in different cities but even in different time zones. Luckily, it’s not a big problem in the modern world. You can always contact anyone online, meet a person and even smile to each other with a webcam, if you are lucky. It takes a comfortable connection timetable to efficiently work together though.
Therefore we are absolutely free in our choice of hiring new people, no matter where they live. With the internet the place doesn’t really matter. Only the probability of meeting offline lowers down.
T — Time
This is the most complicated aspect of an indie remote.
Without financing we need to compete for the time of our employees with everything they have: daytime job, family, hobbies, fun activities etc. Especially often S.O.S. loses to fun. The release of Cyberpunk 2077 slowered us down almost two times! After every team call everyone got back to the game instead of working on our project. It could be noticed in their Discord status… well, what can we do, we love video games!
Game development on remote demands a lot of motivation and self discipline. These qualities we usually appreciate during the interviews and cultivate by any means possible.
There are obvious advantages in speed as well loke: no need to spend hours on road to office and back, colleagues don’t distract you from your current task if you don’t want them to. It’s also comfortable to have asynchronous working hours. People sometimes work at night or in their free time. We are not bound to be all in the same place at the same time. Everyone works in their comfortable rhythms as long as it follows our common deadlines.
Q - qualification
Our team, especially at the beginning, attracted people with very little actual experience in the gamedev. As little as it was not possible for them to execute complicated multicomponent tasks. Partly because of that, we needed a task tracker system. When a person doesn’t know how to proceed with a task with several stages, we have to decompose everything and give them just little pieces of that task. Well, and it’s certainly a must to develop pipelines to show everyone their place in the process. That way an employee learns faster how to work.
I’m not going to declare that this is the most efficient method but it pushes us forward. Low qualification is not a curse if a person wants to learn. Now we have experienced professionals who came already with their techniques. And those who have been with us for a long time became now more experienced. But there is always space to grow!
Everything in its time
Maybe it should have been the first reason of the list but it looks a little “unprofessional” to me. I’m talking about: “was it even possible another way?”.
From the first day we didn’t even think about renting some office space or meeting offline regularly. We are all scattered far from each other with our personal lives, day jobs etc. We are united by our desire to create games and that’s what we do. All other office routines would have taken too much time and resources.
We have of course our plans of working in the office but it will not happen until at least our second product. Some day we will have to change our format of work and create a new core of the team together. If the technology of the virtual workplace would be created before. Then we will gather in VR on our own space station of our own design.
This part covers the time from February 2019 to December 2020. Conclusion: if I could do it again I would have started with the remote work format. It’s a huge resource saver with our modern technologies without a big negative impact on the result. It’s a perfect path, at least for a small team. The managers need to set the balance and compensate for the negative sides. The comfortable work for everyone, that’s what matters.
I keep saying that your desire is the only thing that matters. If all the team wants to make it work then the remote is not an obstacle but an opportunity!
Path Of The Indie - Part 13/15 - Managing The Development Process
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.
The most important thing about managing a team of 30 employees is having enough time for it, and also support. If I hadn't had the enormous desire to found a development studio with a possibility to spend 3-4 hours every day (w/o weekends) then the team would never exist.
As the leader I spend my time on the following (from high to low priority):
Employees, their tasks and communication. It’s daily checks of weekly plans, keeping their focus on the most important things iIncluding conversations about video games, news and other relevant topics.
Urgent tasks: interviews, helping in certain tasks and other unexpected things. Development consists of constant improvised activities, there is always something very urgent and demanding my attention ASAP.
Accomplishing my personal duties: budget management, presentations, communication. Weekly statuses of development, administration of team calls, editing follow ups. I’m sharing the latter with our PM, hoping to delegate this part soon.
Planning and strategy. Not on a daily basis but it’s an important part of the job, especially when you get the feeling of walking the wrong path, losing the focus, paying too much attention to inessential things, imagining new features and thinking about how to implement them instead of moving them into the backlog.
What I don’t do for now is:
Risk evaluation
Working with NDA
Working hours regulation
Complicated analytics and reports
Following up with competitors and their new titles. But I try to play most of the games in similar genre
Real practice example
During the work on game balance (characters stats), there are 3 people involved. First, we discuss it in our meetups: the elements of the balance, what kind of balance do we want, what design documents do we need, who should write them, what else do we need, how time consuming the process is, etc. All the tasks are written down and moved to Jira. During the first half of our estimated time before deadlines I come to every person involved. I ask how the things are, are there any problems and so on. On the next call we have a status reviewing all the results we’ve got even if it’s still work in progress. We verify again our tasks according to our priorities and milestones. We are likely to postpone the deadlines as it’s almost impossible to set it correctly in the first place. As soon as the actual executor finishes his part I accompany the materials to the next person making sure that they are received in time and all is understood by the recipient. Or I take the results to our next call for the future discussion and then make a decision of approval or further transformation.
This helps me to understand the stage of a feature readiness. How it is created and is there any need to interfere, involve more people on this task, etc.
One head is fine but an additional one makes it even better
Obviously, it’s really hard to keep an eye on everything. Our PM helps me a lot with it. We’ve recently started to do short daily statuses together for 15 minutes. Without unnecessary formalities we discuss current tasks and urgent matters. Along with tracking the tasks in Jira, our PM regulates different administrative questions:
Creating polls
Gathering information
Welcoming new employees
Organizing additional meetings
Writing down results and helping all the team to be more efficient
It allows us to keep the focus and double our forces on certain problems without losing sight of less important things.
Required qualities
To lead a team you have to be highly motivated to keep order and systematize everything. You are the one to transform the chaos of game development into something regulated. Well... at the first glance it would look like some Frankenstein thing gathered from anything you could find. But it will bring more clarity, especially for the team. People need to know that the next online meeting is going to happen, that there’s a chosen topic to discuss with the problems to solve, that the results of the meeting will be written down and integrated into the general process. People need to know who to ask for help.
If you have a plan it means you know where you’re going. It doesn’t mean you will get there but there is a destination point everybody is aware of. The leader is the locomotive which drives us there and makes sure nobody is being distracted on the way. The PM rushes between the wagons, cheers people up and sees that nobody drops off, reports back and sometimes defends the team in front of the leader.
This part covers the time from April 2020 to December 2020. The moral of the story: It looks like I'm telling obvious things. Especially, for those who have more than one product released with their teams. However, I wish I could know such things from the start. That’s why I’m sharing this. By the way, we are launching a live-show about our game development work in January 2021. There will be streams of our calls, documents examples, questions & answers sessions and other cool stuff. We are looking forward to helping other indie devs at the beginning of their path. Come check it up!
Start small. Create the team codex and agree on it with everyone in the team.
Team building is not just to have a party together. Especially if your team is distributed. It should be about uniting the team by any means.
You can raise motivation even before getting funding. And secure the shares distribution with legal help.
Good day to everyone, dear friends! The Rummy Games team is here to present you the new Developers' Diary.
Today our developer, Ilya Alenchikov, is with us, and he will tell us about his experience of working as Level Designer in our team.
About myself
My name is Ilya Alenchikov. I am Level Designer and Level Artist on the Saturated Outer Space project.
One day the thought came to my head: "Stop playing games, it's time to make them!" And at the end of 2019 I went to study as a game designer at the Higher School of Business Informatics. Having completed my studies and received an honors degree, I realized that I am not a game designer at all. Yet my dream was to bring games to life, not create them. Vyacheslav Utochkin, a mentor from the Higher School of Business Informatics, helped me find a suitable role in game development. He offered to join the Rummy Games team and try the hand at level design. I will talk about this experience further.
About the tasks
At first I was responsible for integrating the base geometry into the engine. My test assignment was to study the game documentation and design the basic shapes for building the walls. After reworking the circuits, making improvements and other things, we approved our first basic geometry, thanks to which the foundation of any level is built. And our programmers have made several new tools for the engine, with the help of which the objects are placed with rigid binding to the tile grid.
Then I was given a task to “raise” Sector 5.2 according to the scheme of one of my previous colleagues.
The sector was successfully created, but did not go into production, as it did not meet our expectations. It was attended by a large number of narrow spaces that could complicate the further implementation of the mechanics. Postponing Sector 5.2 we started working on Sector 5.3, which has a geometry that is very different from 5.2. Just at that moment, another Level Designer, Artyom Safronov, joined our team. Over time, Artyom began to deal with all the planning and integration of mechanics into the level, as well as drawing its diagrams. And I went deeper and deeper into the creation of blockouts and the selection of the visual component.
Simultaneously with Artyom and our game designer - Dmitry Kondrakov working on the level schemes, I received a new task to work on the interior of the ship, on which the S.O.S. Between ourselves, we call this location the LoSh (Life on the Ship).
Before I started working with the ship concept, another Level Artist who was working on it, that is Sergei Kosenkov (a separate respect to Sergei, for having taught me a lot). Sergei is in our team, although he changed the scope of work. If not going into details, then I just took as an example the semi-finished part of the LoSh (the captain's cabin and his room) and proceeded to design the rest of the premises.
It took me about 6 months in part-time mode of almost solo development to bring the LoSh to a present state:
creation from scratch and 4 alterations of the bar on the ship,
creation of a character upgrade room and its two-time redesign;
creation of the room for a mission landing and changing it to match the color palette of the rest of the ship;
one-time, but significant reworking of the captain's cabin and the main character's room;
double design of the outer space outside the ship.
All this and much more has been done and reworked several times, mainly due to the search for suitable means of transmitting information, mood and mechanics on the LoSh. Colors, shapes, textures, object placement and so on were changed. We'll probably come back to this issue in the future, but so far the concept has been approved.
The first variant of the LoSh
As mentioned above, simultaneously with the LoSh I worked on the first full-fledged game Sector 5.3+. It was based on Artyom's scheme for sector 5.3, but is a fork for a full-fledged demo. That is, in our game you will not find “5.3+”: the narrative and mechanics will be slightly different, although the basic geometry and theme will be very similar. Today, we place the greatest emphasis on “5.3+” and try to iron it out, so to speak. Here I was mainly engaged in the development of the blockout (graybox/whitebox, call it whatever you want). This is a very interesting experience. On the one hand, it seems that it is simple: you sculpt the basic visual component of the level from any available geometry contained in the engine (boxes, cones, circular geometry, etc.) and that's it. But the further you go, the more you realize that everything is not so simple. You can say that you are practically responsible for how the level will look like in the future, you lay the foundation and the logic, mechanics, arrange and bind interactive objects, and much more. This is a fun and challenging process.
The first options for Sector 5.3+ blockout:
Tools for work
- Unreal Engine 4 - Photoshop (creating LUTs for Post Process or, more simply, setting up the color correction) - And a little bit of Blender's
Difficulties in the process
Basically, difficulties arose due to a lack of experience in the engine itself. This greatly impeded the implementation process. Nevertheless, I would not advise the beginners to immediately lean on the UE4 documentation. Of course, this will not be superfluous, but if you want to focus on the visual component (development and design of levels), then I recommend starting by watching various video tutorials on YouTube (unfortunately, most of them are in English) - for example, very good channels on the level design: Polygon Academy and WorldOfLevelDesign. And of course, start digging into the engine as soon as possible: this will help you understand what this thing consists of and how you can much more familiar with it. Also, do not forget to develop your imagination, inspired by other people's work. The Artstation platform, where people publish their work, can help you with this. You can learn how to work with the engine on your own, without special training. The main thing is to put in more effort and be patient.
Final results
The ready LoSh (the ship interior)
The in-between blockout of Sector “5.3+”. Still under development.
In addition to the skills of working with the engine, I managed to gain a lot, a lot of experience in the development of mechanics, game design, as well as in team interaction!
Future plans
I will continue to work on the project and walk through this difficult path with the team. I will concentrate my efforts on the blockout and design of the visual component of the levels so that you can enjoy playing the game!
All the best and see you soon in the open spaces of the galaxy!
Path Of The Indie - Part 12/15 - Team Building
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.
I’ve already mentioned in these series of articles, why people came into our team or how they left. There is not much more to add to it. But I can also tell how we support and motivate each other. Let’s discuss this popular term “team building”. I was told once by someone very wise that the best team building is to release a game. That’s all! The advice was to forget about anything else. I will not argue that the release is a very special thing which can change everything. And the more successful it is, the more motivated the team would become. However, we should also think about all the way we need to go before the release!
How to motivate the team on the way to the game release
We started with a simple set of rules to live by and function as a team. We named it our “codex”. The most important things are:
Respect other team members
Try being objective
Do your work as good as you can
90% of the job done means the job is not done
Don’t lie
Be in touch if possible
Generally speaking, all those rules exist to support a healthy and productive environment in the team. Newcomers get to know those rules as soon as possible to successfully integrate in the team. We don’t control how everyone behaves but in 1,5 years we had only one case of a person being disrespectful in communication. We don’t work with this person anymore.
I - Immersion
As we have been working remotely from the very beginning and all the team members are scattered from Saint Petersburg to Petropavlovsk, we don’t see each other very often. Actually, I still haven’t seen all the people in real life, and with some of them we met only via webcam. But those who can come to our live meetings, gather quite regularly. Public events, conferences, exhibitions, tabletop games sessions, Christmas parties in a bar, we have all of that. It adds more reality to our work. People see their colleagues in real life. They get to know each other from different new sides and begin to believe in our indie-game project even more! You know, it’s amazing to finally meet someone with whom you’ve been talking in discord for half a year.
In our team the offline meetings happen spontaneously. Don’t discard the moments like these and try to cultivate them. Even if you don’t release the game, at least you will have something to remember! Indie story is not only about the product, it is also about the path to go on the way there. All the transitional stages have to be valued too and not ignored. Sometimes you need to relax!
The culture of team communication gets cultivated exactly in the moments of real life meet-ups. Thanks to the informal style of interaction, the adaptation is really fast for everyone. Everything goes smoothly without any awkwardness.
C — communication
I see our regular conf calls as another one instrument of team building. I’ve already mentioned in the previous post that every Monday we gather for the whole team online meeting where our PM and I tell about the team’s achievements and results for the week. We inform others about the project’s progress and set our short term goals. Sometimes we organise lectures about lore, discuss some general questions, plan other calls for a week and praise those who did especially good work. We can also openly discuss the opposite, if someone didn’t deliver the expected result. It only sounds mean, we try to do this in a productive way with encouragement and suggestions to help.
We all have a common goal for our project: to go till the end and get a successful case for the portfolio. Everyone wants to see his name in credits. But our work is not limited by this result, sometimes it’s a learning process which means investing in oneself. We give the opportunity to use our game as a graduate project if needed.
Our mentors help us grow too, providing their expertise and experience, giving us new impulses to move forward.
Gamedev is one of the unique environments where people don’t just earn money but they also have fun, make friends, learn and grow, and all this is the part of the deal! We all came here not to just create games but also to find like minded people, new knowledge and next level-ups.
M — money
If we return to a more mercantile point of view, I can remind you of such things as options. You can always discuss and prepare a system of personal rewards, related to the release or the funding by investors, and make everyone sign the document with those agreements. It’s better than to have questions like “I don’t remember that we discussed it” later anyway. There are more official ways to secure the agreements but you’ll have to go to legal experts.
This part covers the time from May 2019 to August 2020. The moral of the story:
Start small. Create the team codex and agree on it with everyone in the team.
Team building is not just to have a party together. Especially if your team is distributed. It should be about uniting the team by any means.
You can raise motivation even before getting funding. And secure the shares distribution with legal help.
Path Of The Indie - Part 11/15 - Processes And Pipelines
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.
So why do we even need any regulations instead of just being creative and enthusiastic? Wouldn’t those frameworks limit our imagination and kill all the creativity? I have no idea. I think every team has its own path. We chose one with sequenced processes and some SCRUM methodology implementation.
From the very beginning I tried to organize at least a partly functional system of efficient processes. To make the game creation transparent, understandable and simple. I tried to found some basic planning, foremost for the team, not for myself. I understand that it could sound like overthinking but systematization is my passion. And as I couldn’t develop a game myself my options were:
Learn how to do it and do everything by myself. Not my case.
Find someone who could do it. Draw them in. Simplify processes for them. Systematize everything.
I will tell in this post how our work is regulated to make the information circulation easier and with minimum distortions.
1# Necessity and Sufficiency
It was essential not to overload everyone with planning and reporting. But it was also important to keep an up to date task list of every team member. At first I took it all on me, created Jira for the team, created projects there according to development fields: code, game design, art, administrative work etc. Our task tracker is not a manager’s whip. It’s just a task list divided by type, deadline, responsible, priority and other useful categories. At first it was me setting tasks, and in the majority of cases it was also me closing them, even for actual executors. Now it’s our project manager’s job. What is in it to the team? Every member has a personal task list with priorities. Everyone knows what has to be done now and what to do next. It helped us to eliminate unhelpful questions like “I don’t know what to do” or “it’s not my job”. We don’t insist on closing the tasks, the priority is to accomplish them.
Along with the task tracker I also started to use Confluence, not only for the project documentation but also for follow-ups, logging all important decisions made.
Apart from those two programs we soon felt the need in a version-control system which was acquired not by me this time but by our programmers. We had been using Git from the very start. For cloud storage we used BitBusket but soon moved to GitHub.
In my opinion, those three instruments are the necessary minimum for any team. You can option to use Trello and Notion instead of Jira and Confluence if you like. I know that there are also Google docs but it’s a must have anyway, I don’t even consider our work without them.
2# If it’s not written down it doesn’t exist
As our team has more than 3 people the information needs to be stored somewhere separately from our own heads. That’s why we have the rule to write down everything on Confluence: decisions on game design, lore changes, objects or units changes, tables of characteristics, assets, content plans, pipelines, marketing strategy etc. Some things aren’t well suited for Confluence, then we attach the link to the following document or resource. If something isn’t written down with the text or link then we surmise that we didn’t discuss it at all and therefore it doesn’t exist.
Apart from keeping the important information we gain another benefit: everything not written down is thrown away without overloading our backlog. It means it’s not important enough and can be dismissed.
3# Create and use pipelines
The power of an indie team is in its flexibility. But when in every development sector, in level design, for example, there are few people participating, then we have to regulate it somehow. Otherwise everyone will pull it in different directions. At first we tried to create pipelines in table form with deadlines. It was a failure, no one followed it. Then we tried “simple” pipelines on Miro explaining the place and interactions of every employee. It simplifies onboarding and administrative work as there’s no need to explain the existing order of things every time.
Pipelines are not being followed by 100% but it’s always better to have some plan than nothing.
4# Unified communication environment
It’s important to agree from the start on the platforms for communication and information exchange. We use Telegram for general chat and a few thematic ones: level design, art, marketing, programming. Project manager makes sure that all commitments with their deadlines find the responsible employees in time.
5# Constant feedback collecting and communication flow
Weekly calls evolved too, so now we have several calls per week, all devoted to certain fields of work: general meeting for the whole team and specific ones where different team members are gathered: level design, art, marketing and content with game design.
I’m grateful to our programmers who did such a good job in organizing their working processes that I don’t really need to involve myself in their work. This is a perfect case when a department doesn’t need to be regulated by administration.
So I named all the most valuable instruments which help us keep track of the tasks and the information.
I think that’s enough and involving more administrative instruments could be excessive and even unproductive. People have some actual game development work to do too. In the perfect world only PM has to work on all those resources closely, when other team members only use it as a unified wiki of the project.
This part covers the time from February 2019 to October 2019.
The moral of the story: team leader, administrator / PM is not a person who demands from everyone the work to be done. It is a person who makes their life easier, organizes the processes and makes the tasks and deadlines clear for all. It’s the light at the end of the tunnel, not a train behind you.
What have to be done to lead the development in a team:
Established work structure helps to keep a unified information field for the team;
Unified communication environment, constant logging and updating the data minimize the information distortion
Feedback and communication are needed for everyone to feel they are part of the project. Creativity is growing on the information exchange, that’s how new ideas and inspiration are born.
Systematization demands certain management skills and at least two administrators who can back each other up
Good day to you, People of the Earth! The Rummy Games team is here, and this is another Developer Diary. Less than a month is left before the New Year, but we do not even think to rest: we continue to work on the project.
Igor Konyaev is back in touch with us again, this time he will talk about the main architecture of the game used for prototyping. All further material will be presented on his behalf.
About myself My role in the project is Technical Game Designer and Lead of the UE4 team of programmers.
About the project Saturated Outer Space is a tactical turn-based strategy game with RPG elements. The game has 2 main gameplay modes: turn-based (like in XCOM) and real-time (like in Mutant Year Zero). I will speak about the game modes separately below. In addition to these two, the game also has a hub-mode between missions on a spaceship.
What I can share without claiming it to be an authoritative opinion Experience in game prototyping using the basic "clean" architecture of the project. This is an approach when part of the game mechanics or game systems are prototyped in conjunction with the main architecture of the project. For example, programmers make a tile system of movement, lay down complex algorithms for finding a path and develop a system of abilities for characters, and a game designer, based on the interfaces available to him for low-level logics, can prototype new mechanics.
What is prototyping? Prototyping is a broad concept, so in the context of this article I will divide it into 3 categories:
1. Environment prototyping. Basically, it is the work with geometry in order to create the desired atmosphere at the level (level design);
2. Prototyping game mechanics. This is the creation of those same attack or grenade throwing abilities for the purpose of testing them;
3. Prototyping game systems directly related to user experience (UX). For example, the number of degrees of the camera spareness, its incline and height directly affect the user experience of the player.
These three categories are united by tight deadlines for completing the task and the goal of testing one or another game component directly in the engine in order to understand how viable the mechanics are on paper, and in real game conditions. Further I will describe 3 different cases that I had to face while working on a project, both from the programming and design points of view.
Metrics At the very beginning of the development of the main architecture of the game, which, according to the idea, should turn into a vertical slice, I was to describe the toolkit for creating level blockouts, relying on the fact that the game will have a step-by-step mode in which the rules of rigid binding of geometry objects to tiles must be observed. Looking ahead, I will say that we decided in the team to use a combined approach when creating blockouts. We combine geometry that is rigidly attached to the tile grid with geometry that does not affect tile navigation and the sight line (visibility) in turn-based combats:
Some self-test questions:
What is the optimal tile size?
What is the difference between "thin" and "thick" geometry?
How to connect primitives on a tile grid and what kinds of geometry should there be?
What is the optimal height for walls and doorways?
To find the answers, it took me a lot of time in various turn-based games, observing how the technical side of the game worked. This helped a lot to understand in which direction to go when creating the placement toolkit - adjusting the geometry on the levels. It was also important for me that some of the games in question were developed on Unreal Engine 4. If you have an understanding of how the engine works, it’s easy to catch common patterns and make sure that you are on the right path when developing, or not.
But let's get back to the questions. After studying several competing games, it was decided to create a tile with combined sizes and divide it into 2 areas:
Here the area circled in red (1m by 1m) available for placing units and geometry. Specifically for the unit, this zone is the maximum allowable size. This means that a unit can take cover only along the border highlighted in red, here you need to clearly understand what dimensions your characters will have. The open area between the blue squares (40 cm) is used to accommodate "thin" geometry. An example of placing "thin" geometry:
What is the difference between "thick" and "thin" geometry:
The good thing about "thick" geometry is that it can go beyond the blue tile and take up part of the unpainted area between tiles. In this case, you can avoid that the character sticks to the wall with a large gap, as here (the thin wall by default is devoid of these problems):
The conjunctions of geometry with each other now has a very simplified form, since the geometry toolbox uses primitives. Further, when using assets, a similar method of connecting objects will be applied:
A list of all possible geometry was also compiled: walls, columns, corners, doors, shelters, etc. General view of what was realized:
It is also useful to have a separate map on which all the same geometry objects will be located, but only in the form of a Box Brush. It helps a lot if you need to change the metrics of an existing geometry and create new static meshes.
The optimal height of the walls and doorways was the most difficult thing, since it was necessary to immediately take into account the height / width of the largest character in the game and the parameters of the camera (tilt angle and height). I will touch upon working with the camera separately. To measure the height, you can use different tools, some create special helper meshes that immediately have specific dimensions (1m, 2m, etc.). In this case, I used the tallest characters that were available, and an additional layer of a tile grid that can be raised to any height and get an overall picture of heights at all levels:
Let's summarize the level design tools. In our case, the tools were originally woven into the main architecture of the game, since it is very important to have a standardized level development system at the very initial stages so that level designers can immediately get used to the basic metrics. Almost all game logics are tied to the tile system; this is the foundation for the game. During the development of the tool we used only C ++, blueprints were used to quickly test some hypotheses, and after passing the Proof of concept stage, almost all low-level code was ported to C ++.
Prototyping game mechanics using the example of the ability to throw a grenade Because the game is turn-based, it is difficult to separate the architecture from the prototype when prototyping. One should understand how this or that ability will work in a step-by-step environment, so the ability management system was originally built into the main architecture.
Let's look at an example where it is needed to prototype the grenade throwing ability. My approach is very similar to the one in the last paragraph. First, we look at the competitors and compare our understanding from the design document with how other developers solve a similar problem, after that we evaluate the possibility of rapid prototyping. Questions for self-test: 1. What methods, events, variables or classes from the main architecture are available in the blueprints? How difficult would it be to build a small prototype into a large system? And does it make sense? 2. How will grenade targeting work? Usually this is a sphere, the targets of which are objects crossing it, or objects that are located on a conditional area with dimensions of 3 by 3 tiles;
3. Is physics of a grenade flight needed? What will be the behavior of the grenade when thrown? Will there be a collision with other objects?
The issue of embeddability is always individual, for this we try, whenever possible, to always open access to the logic that is written in C ++. In the case of the ability to throw a grenade, there are a number of methods that need to be redefined in blueprints, cause recognition of the target (an attack is possible or not), and apply the necessary modifiers (take away HP from the target and action points from the player's unit). It makes no sense to show the code, here the idea is only in the availability of low-level logics from blueprints. If prototyping mechanics takes an unreasonably large amount of time due to the fact that the programmer must be distracted from other matters by opening access to variables, then it makes sense:
Prototype mechanics without touching the underlying architecture;
Give the programmer the task to immediately build this mechanic into the code. Several times I heard from people that on their projects they have a team of cool programmers who write prototypes in C ++ even faster than a game designer can do on blueprints.
In my opinion, it is best to immediately write the code in such a way that in the future there will be as few places as possible where you need to put UPROPERTY or UFUNCTION.
In the current prototype, targeting works as follows. When a player levels the sphere of grenade throwing, then those targets that intersect with this sphere are highlighted, everything is simple here:
But there is an alternative way to select targets - tile highlighting, as it was in XCOM:
In the case of XCOM, only those targets that are on specific tiles will receive damage, but it will be visually clear that the grenade circle partially covers a few more tiles that are not taken into account by the system. Now we have made the first option, as it seems more understandable for the player, it does not contain empty spaces that are in the case of XCOM. But our option is poorly suited for weapons or tools that can apply or remove an effect from an area, or depend on the range of damage. For example, if a fire extinguisher partially cuts off fire tiles, it will look strange. On the contrary, a fire extinguisher that works like an XCOM grenade looks much more true.
Another step in the work on the ability of the grenade was to determine its behavior during flight. At the prototyping stage, it immediately became clear that the simulation of the physics of flight was not needed at all due to the fact that the battle was always turn-based. It was enough to calculate the flight trajectory for the grenade and make it off the hand at the moment of the throw. Then the animation of the flight through the timeline will do everything by itself. When the grenade reaches the end point of the trajectory, an explosion event is triggered: https://youtu.be/YHo3zt3OYB8
The bottom line for prototyping game mechanics:
Do not neglect the main architecture of the project, sometimes it is vital to test mechanics in real conditions, and not in an isolated environment;
If possible, try to open access to as many game logics as possible if you use blueprints for prototyping;
Estimate the real need for things like physics or realistic destructibility. This is expensive and the gameplay value can be zero.
Camera prototyping I must say right away that today we have 2 cameras. Each camera is tied to its own game mode and has a top-down perspective: Camera for turn-based combat. Flies around the map freely, is not attached to characters; Camera for real-time mode. Attached to the selected character, limited in tilt, free rotation around the Z axis. The most relevant examples are Mutant Year Zero or Divinity Original Sin (playing with a gamepad).
Again, I'll start by seeing how the camera works for others. What is in the design document may run counter to the gameplay.
As a result, for real-time mode, almost the same angle and camera height was chosen as in MYZ, the camera was fixed above the selected character to increase immersiveness, and the tilt was completely limited to exclude flights through geometry and the desire to look at the ceiling. For battle mode, the camera is currently identical in parameters.
The results of the camera prototyping strongly affected the level metrics. The base geometry dropped from 5m to 3.6m. You can compare how different the geometry was before and after finishing the work on the camera. Before:
After:
Next, the work is planned on the multi-layered geometry, which will be hidden depending on where the player is looking.
Outcome From my own experience, I can say that you can successfully combine the main architecture with prototypes, the balance between the labor costs of a game designer and a programmer who will prepare the infrastructure in the form of tools and API is important. Once again, I repeat that in the case of our project, this is necessary, because gameplay mechanics are inextricably linked with step-by-step (the rounds system) and a tile grid, and it is inappropriate to let the game designer prototype such things separately due to their complexity.
*** That's all for now. Feel free to comment and rate this diary. If you are interested in the project, subscribe on social networks and add the game to the Steam Wishlist.
See you next time!
Us on Twitter - https://twitter.com/mvmvgames Us on Reddit - https://www.reddit.com/user/mvmvgames Us on VK - https://vk.com/saturatedouterspace
Path Of The Indie - Part 10/15. - Funding Our Game Part
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.
When we started our project we didn’t have a clue about investments. The goal was to get the developing experience and release a video game. Minimum efforts, minimum waste of resources and time, minimum quality... But everything has changed. During the development we changed our mind about releasing the raw game project on Steam. We decided to become a real studio and to create a real video game. It meant financed development. To accelerate experience gain, to make a game not only capable of selling itself but also to return the investments. So we needed to start building some corporate strategy basics and looking for investors. We also needed something to show — a pitch and a build. Therefore we needed to know how they are made, where to go, how to prepare.
Who in the team should be responsible?
Yes, the correct answer is biz dev. Hire one and let him or her solve all these problems. In the summer 2019 we couldn’t find a decent business development manager. At first I scouted among my acquaintances. I found one candidate and told him about our project. He was interested enough to come from another city to talk. Well, okay, he was passing by Moscow for some other reason but nevertheless came to see me to discuss the project, which apparently shows some interest. After listening to my detailed story about finding investors he started to question our game design. Although his experience was mostly in business and not in games mechanics he was somehow more interested in product than in business development. We parted ways. Our need for funding didn’t go anywhere. I came to the thought that no one knew the project better than me so I was the best candidate for the mission. In indie teams leaders should think about investments by choosing the way of development and negotiating conditions with potential investors.
Although the biz dev job had become a bit discredited in my eyes, in the summer of 2020 we gave it another shot: for now we have a person who works on investment hunt simultaneously with me. I don’t have any conclusions for now, the time will show.
Our first attempt funding our game
In August 2019 our producer shared an interesting information about Irish fund CSF financing any kind of start-up for 50 thousand euros 1-2 times a year. The only condition: a good pitch. No matter the industry, project stage etc. We even knew someone who actually received 50 thousand euros just for an idea of a mobile match-3 game without a prototype! I was of course excited to start preparing our application. Without any previous knowledge I approached this task with maximum responsibility and brought some order to our understanding of this process. Unfortunately we didn’t make it to the second round because of overestimated forecasts of revenue. The Irish didn’t believe our numbers, and for a reason. Our business plan looked like a financial pyramid. The first lesson I learned was: don’t lie to a potential investor. Investors aren’t stupid and they will not be fooled by juicy numbers without grounding.
Second Try
Strictly speaking, our second experience was another application to the same CSF in January 2020 but it failed too, although for another reason. They were fine with our financial part but refused because they weren’t interested in games funding anymore. It wasn’t their profile. Maybe it was just a polite way to say no but I didn’t care. For the same reason: if they don’t specialize in video games it means they don’t understand much in our industry. No additional expertise and not so good money. Besides CSF we tried to find investments among our contacts. To make the pitch more attractive I remade our presentation and prepared a roadmap with budget indicators. After several meetings we still didn’t have any satisfying result. However, I trained my presentation skills and learned a lot about pitching. I also learned that it’s important to have an answer to the question: “what is the structure of the studio and how the profit would be distributed?”. What we will give to our potential investor.
Third and so on
After first attempts my knowledge in investments was still quite poor so I started to study the theory. Google gives you tons of guides and resources for the question “how to find investments” but it’s such an abyss of information that it’s scary even to look into it. That’s why I began with my favorite podcast “How to make games” by tags “business”. And only then I turned to articles and experts. I made lists of potential investors and publishers, and composed a plan for pitching. I’d like to point to the most useful resources:
Two great articles on unrealengine.com about investments: part I and part II.
An interesting book by Brad Feld and Jason Mendelson, Venture Deals: Be Smarter Than Your Lawyer and Venture Capitalist. It tells about investments in the big corporate world of business.
With some gained knowledge I applied to the first session of GDbay contest. As a result I collected valuable feedback: information in the presentation was still not structured enough with the emphasis on less important things. Our producer helped us too: introduced us to a cool mentor — Danila Kamenev. Thanks to him we started this series “the path of the Indie” and also finalized all the required documentation for pitching apart from presentation, budget and roadmap: the project passport, GDD, concept, team information and structure. All this is required if you pass after the first meeting with the investor. In July 2020 we went to mentoring dialogues by DevGamm. I’m deeply grateful to the mentors for their practical recommendations on the presentation, the list of funds, advice on marketing. They were the first experts who returned with very valuable feedback from an investor’s point of view.
What do we have now?
Our main achievement for now is getting to participate in Game Innovators. We were accepted thanks to our completely prepared documentation: presentation, pitch, clear goals and investment proposal. During this program we meet industry experts who help us with counsel, networking and push us in the right direction. This activity will end in mid-December 2020, and I will write about its effects. Overall, the funding quest is a difficult and long process. Especially for an indie team with neither recognition nor experience in gamedev. But it’s not hopeless. We continue looking for investments and those who will believe in us and our motivation to make an excellent product and found our own development studio. P.S. I skipped the part about applying to funds such as EMG, IndieFund, Xsolla Funding Club and others. But it’s only because for us this means only a correctly filled application. Which mostly depends on the same documents we have prepared before. Copy the numbers and the text, paste in 20th application and go to the next one.
This part covers the time from September 2020 to October 2020. The search for investments requires:
Knowledge of the subject itself. You have to study the kinds of funding, how does it work and what do investors expect
Preparation of certain documents. Concept, budget, business plan and pitch-document (presentation) — that’s a minimum. The first stage is often formal and strictly regulated, bureaucracy is more important than your speech.
Keeping in mind not only the funding itself but also connections, expertise and business experience you can gain with an investor. This is one of the reasons why you should always prefer investors experienced in the game industry.
Honesty. Don’t overestimate the potential revenue if you can’t confirm it with strong arguments. The experienced investor will catch your bluff before you know.
Patience and persistence. Even if it is not the 10th time, it will happen eventually. Follow your path, keep improving your skills, your team and the project and it’s going to work out just fine.
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 9/15 - How We Let People Go
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.
For most indie teams staff turnover is a painful and complicated process. Almost every person has a unique responsibility for a certain part of the game. That’s why when someone leaves it’s almost like a family divorce. It means a loss of something indispensable that had been playing a very important role. There’s always a risk of someone leaving the team. How can we approach this risk from a management’s point of view?
Back up. We have a folder named “Reserve” where we keep potentially useful contacts. That’s our insurance in case someone leaves. One to go, one to call.
Minimize. Don't put all your eggs in one basket — here this principle works perfectly. Take 2-3 people for one job and distribute the most difficult tasks between them. Help them to work together, encourage regular contact and information exchange. Here the role of Project Manager grows: I wrote about it in the 4th chapter and there will be more to it later. As an example, if there are two people working on level design, then the leave of one wouldn't stop the entire process. The second one would pick up all the tasks and could continue the work up until a certain point. We had a similar situation when our 3D modeler working on units' models left. His coworker Maxim took his place and as a 3D lead started to do systematizing and pipeline setting. That helped us to establish an adequate pipeline for 3D modeling. Pipelines serve to minimize the risks too, I will return to this topic in the 11th post
Dismiss. Sometimes the risks exist only in our imagination. I could start worrying about a person who is working alone, that he or she would leave. In such cases, I usually try to keep in contact and communicate closely with that employee. Often that's enough to dismiss the worries and stop being paranoid. I state for myself that everything is fine, no one is leaving.
Accept. Or simply come to terms with it. If it's not a key position (they shouldn't exist by the way) or there are other more important things demanding your attention then you better just let it go. In such situations, I usually weigh the urgency of the question and if I don't have any means to resolve it then I just stay cool. I let it go if I don't feel that "my bike is already on fire".
Those are my own techniques but there are many more and every leader has a different set of methods coming along with his or her own management style.
Thus we are approaching the idea that even if staff turnover is inevitable, it is manageable nonetheless. As for today, every second person in our project has been replaced by someone new but it didn’t become a catastrophe.
People leave for very different reasons: they get tired, find something more interesting, change their lifestyle or priorities, have a baby, etc. It's often a shame to let them go but there are exceptions. We had a case when a certain job was "doomed" and employees kept changing for 1 year. And then finally we got two specialists in spring 2020 who are working till now and we're all really glad to have them in our team. So don't be afraid to let go, if you feel that it's not working somehow. The signs are:
There is zero profit from a person
There’s discomfort within the team, which is really important for indies
There are big lags in work progress, like when you don’t see any progress for weeks
And some other alarming things.
Of course, every situation is unique and should be considered with all accompanying circumstances. There are no strict rules here but you stay on guard with those signs if something goes wrong.
In the beginning, we all thought that together we would create the next X-COM 2 in a couple days. The reality proved to be different. However, if a candidate has strong motivation and you get along well, then it's the right decision. Look for like-minded people for your team. Sometimes it's even more important than finding a skillful specialist. When employees become like brothers-in-arms they don't drop off by any chance, and you too would want to keep them no matter what.
More details about the nasty business
IMHO: terminations are the hardest thing in management, It’s an easy and often pleasant thing — to welcome newcomers to the team. Terminations carry potential scandal and stress for both sides.
The task here is not only to point to the exit door but also to do damage control by preventing risk of any harm. This should be a leader's responsibility. A leader should explain plainly and genuinely why it's time to separate ways. A leader has to orchestrate this process in a way that the employee wouldn't hold a grudge by leaving the project. And if there are still hurt feelings, it has to be against the leader, not the whole project or the team. Think here of a leader as a lightning rod.
How exactly to do this, it's more a personal choice. I don't know a perfect formula but what does really help: writing down all the cases of poor performance or unacceptable behavior and, if needed, to present them openly. In most cases, though there is no such need. If you have been recruiting adequate people then they themselves would prefer to leave peacefully. But better be ready for the worst.
Let’s invoke here once again a Project Manager’s role, how it goes hand in hand with basic regulation of termination processes. If the decision to “fire” someone has been made then our PM picks up this task straight away by:
Excluding this person from all communication channels
Changing the passwords in-group/common resources
Extracting all the materials that had been made by this person during our work together
And other things.
All this has to be done quickly and scrupulously. If there was tension then it's better to "cut off" a leaving person as soon as possible to avoid any risk of harm to the project. PM needs a carefully designed system to perform all the steps with maximum efficiency. Nothing too complicated, but it has to be thought over in advance. However, this is a precaution, not our usual style of management.
This part covers the time from April 2019 to August 2020. The moral of the story:
Don't be afraid of letting people go. Staff turnover could be very useful bringing with it new enthusiasts with a refreshing vision
Managing the risks of losing team members and will save you from dire consequences. For a year and a half, there were 61 people in total in our team, and 30 of them are working now. All 61 brought knowledge, experience, and helped us to focus our efforts.
Be prepared to make hard decisions and take responsibility. Especially in moments of terminations. It’s the leader’s burden. Don’t put it on someone else, however disgusting it wasn't for you.
