Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
June 3, 2020
arrowPress Releases







If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

Lessons in making a serious game during Covid-19 crisis

by Kim Kupiainen on 05/22/20 01:14:00 pm

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

"Although there are known, effective treatments for mental disorders, between 76% and 85% of people in low- and middle- income countries receive no treatment for their disorder. This is the problem we are trying to tackle. And we want to make games that matter"

This is the line I had in our first pitch. It was a make it or break it deal. Normally the teachers have set boundaries on how big the project team can be. The limit this time was 6, and our team had 12 people in it, and I was responsible to nail the pitch. I had to convince the teachers that we can do this. Luckily, I came prepared.

Before the project had even started, I started contacting psychotherapists, in the hopes of finding a person that could help us with this project. I found A cognitive psychotherapist who was interested in the project. This was valuable for our team and my interests in serious gaming too. 

I had already build our project management pipelines, URLs to important folders and files like GDD, TDD etc. I had also given leads their positions and negotiated with everyone about this project: What are our roles and what are we aiming for. The only question we didn't answer at the time was: "How."

The teachers wanted me to make an organization chart because we were so huge compared to the rest of the group. This was extra work, but it was justifiable because we were a group of 12, where the smallest group was a group of 3.

I did the organizational chart, went to the pitch shaking, and did my best. There were some really good questions from the other students, such as: "What's your estimated playtime", where my only answer at that point would be: "Quality over quantity. We do not know."

In the end, we got the permission to go on.. All except one teacher gave us the green light. And when asked why not to give green, he said that he "did it for the memes."

I had played this war of mine, that dragon cancer and bunch of other serious games, and wanted to dip my feet into making a serious game too. The last project was a mobile game we made with a really obscure engine called Urho 3D, this time we got to work with unity.

On behalf of the technical side I was interested in experimenting with realistic graphics, building emergent gameplay together with the community and making solid sound design. The team agreed. We started building a game with the aim to give tools through gameplay, for people suffering from depression. Our design pillars were:

1. Not to gamify depression, but instead give support through gameplay experiences.
2. Make a puzzle game with aesthetic environment.
3. Learn more about serious gaming
4. Be truthful about the scope of the game and the amount of work it takes.

With the first Vlog of our project, I made a personal record of gaining around 1000 views on the very first 24 hours for a game I'm involved in making. However the hype slowed down after a week or two, as we were onboarding a new marketing person to take some weight off of my shoulders so I could focus on applying for grants and doing production. This person became busy with other things in his life. He was active during 2 days of our development. Rest of the days he was missing.

In the meantime our Discord community grew to around 54 persons with the first Vlog and some marketing I did on Reddit. I did my best to make the new members feel welcome and created channels for anything I could think about. Be it info about the project or #animals or #music -channels. In the end they seemed happy with the Discord we'd build them. I started applying grants for our project.

We started the grind. Learning GLTF 2.0 related asset pipelines, building prototypes of the puzzles fit to the game, networking pieces, subtitle systems, saving system, shaders, etc.  Our Designer worked closely with our prototyping department and our Art Lead. I took care of the daily standup, retrospectives, making sure that everyone knows what they are doing and that they don't have problems, and of course making sure that they are feeling well. one-on-ones were in the beginning weekly, and after preproduction bi-weekly.

Among that work I was organizing play tests for our community. In duration of 3,5 months we tested the game with our community twice. We could've tested more, but thought that this will suffice.

The Artists made a huge amount of beautiful art. The tasks on behalf both programmers and artists were super heroic at times. The team didn't exactly understand the concept of Scrumban, or retrospectives, even as I had done my best to explain to them how they should be done and why.

I had given a course on how Hacknplan works, and how it is used in the beginning of the project, and said that there should never be a task that's over 8 hours long. If it's past that, then we should divide it into multiple tasks.

In hindsight, I think that I should not have given a spoken course about project management, but instead let the team learn together with me and practice logging tasks and building plans beforehand. If I want to build an environment that's beneficial for learning, play has to be a part of work. And such it should be especially in the beginning.

I was thinking that you can't do and learn at the same time. Which in a way is true, but doing creates routines. So by "playing" that we're doing something would've been more beneficial, than this 1 hour course of hacknplan project management features, guides and pipelines.

The biggest task in the backlog is currently around 63 hours. It's done, but it hasn't helped me do my project management part of my job well. However we were surviving to my knowledge until the finish line. And we went through this same problematic theme in 3 different retrospectives. This makes me think that maybe it didn't help to talk about this, because the "wrong pipeline" had been learned already. The only way I could correct it is to have people unlearn it and relearn a better way.

I was sick for two weeks in the half point of February. At that point our asset prioritizing mainly consisted of singular objects that didn't linearly add value to the gameplay.When I asked our art lead about them being finished he said they're done. We didn't exactly share the train of thought about what "done" stands for. I thought that done means that the art assets are made, and implemented to the engine for programmers to use. However all the assets were sitting for some time in dropbox, waiting to be implemented instead of getting implemented and then calling them done. So that was the first misunderstanding with our Art lead.

Cue Covid-19 rising up in Finland. At first it was just minor news. But it grew pretty fast, I said to my team that I'm pretty sure that in around in a week, we wouldn't be returning to the school for some time, and we should start mentally preparing for that. Unfortunately enough I was right. We started to learn to work from home. I built our team guidelines for working from home.

  1. Our official work times are from 08:00-16:00. However everyone's required to be present from 09:00-14:00 unless medical issues or some other major reason
  2. It's very easy to misunderstand people when communicating only through text. Rather use voice chat to elaborate and go through things in detail. but write it down.
  3. Keep all documentation related to our project in as few places as possible. Onedrive + Repo + Dropbox. Do not keep files in 38 different places and remember to always back up to a cloud! Never store on your C drive.
  4. Have a good firewall and antivirus, and even a VPN, on your computer. Don't let the kids play on the same machine that you use for work.
  5. Wash your hands. Keep the air in your room clean. Eat and sleep in a different room than you work in if possible.
  6. It can get lonely at home. Taking regular 5-minute breaks to stretch, grab some water, or talking quickly to a friend really helps. Try making your own lunch every day, or do meal prep on Sundays. Eating well will make you feel better. Also try to go for walks if possible.
  7. Turn off your communication channels once your workday has ended. You have a life outside of your role at work and it can be very easy for that idea to be lost when working from home. Remember to love yourself and to not over-work.
  8. We're a team and we're all in this together. There will be mistakes and growing pains. This is normal. Ask questions, be supportive, listen, and be patient.

After the second half of the project. I became also the audio guy. I started learning FMOD, and after a 2 week intensive course I held to myself, I could successfully use FMOD pretty fluently, because I have studied Audio-engineering and graduated as a media-assistant. It took me around 2 more weeks to make around 135 sounds to our game, in addition to the soundtrack with 8 songs, of which I made 6 of while doing project management to the best of my ability.

.

While I had my head caught up in the Sound design, I thought that the project was going well. After that I noticed that our Art team had started slowing down, and begun being somewhat inconsistent with the implementation of the art assets.

I asked the art lead about task prioritizing. He said that to his knowledge they've done all the tasks that are needed currently. Me and him together went through what they had done, and realized that while they had done more than they were asked, they didn't necessarily do the tasks in the most efficient order. And we were going to move from production to polish in a week.

There was a sauna that had been made for the game before we had all of our trees for the game scene. I think that it's most important to have things that you see most of the time, be of the greatest fidelity. Because the player sees trees everywhere, but the sauna is seen in a single place on a 2 square kilometer island.

As a lead/Producer, I like to give more faith to the leads than is comfortable for me. I do this because I believe it creates a foundation for self-guidance and as we're in school, We're not in danger of losing our jobs. I believe in facilitation of communication, and making sure that we have everything we need to push the project through. It also teaches me to let go, instead of slowly falling in to the void of micromanagement.

As we moved forward, the art assets started pouring in, but GIT was a new concept to the artists, most of the assets had to be reimplemented multiple times, as assets would go missing from the project folders and people in the art branch didn't exactly know how to use these kinds of tools.

This is no surprise, as version control is something that is not gone through actively in art-studies of game development in my school. The problem was tackled by us though. Our programming lead made our artists a simple documentation that went through how to push and pull, how branching works, how to build a feature branch, merging and so on. Artists started trusting their skills and started pushing more assets. At this point, a fire was brewing somewhere else.

We moved from production to polish. No more assets would be added to the game. At least that was what I promised myself.

Our programmers in the team started merging scenes together to make sure that every and each puzzle works the way they are supposed to. We ran into problems with git, problems with merging, communication and constant breaking of heard information due to bad Internet service providers.

This put us backwards in development from the schedule, but not by a lot. We had one crunch weekend and I personally have this night, when I'm going through everything I've learned, before going to the stage to present our findings and lessons from the project.

We worked 7,5 hours a day, 3 days a week. Putting us in to 4282 hours of development time in total on duration of this whole project. With crunch we gained more time to do useful things, but we did not make a perfect game.

Everyone was present for the whole day to the best of their ability. Even though we had to go to school from home. The lessons while going to school from home took a toll in the quality. And so did our project too, obviously. Because many problems can be debugged way faster when working in the same environment.

In the end, we have all the puzzles that we originally designed, but the implementation suffered from the beginning and the way people had been working separately.

20 items in the backlog, 7 in the last sprint. All with the tag: CUT or bug

Here begins the TLDR part of my first blog post on gamasutra.

Lessons learned:

Production

  • Pre-production of 4 weeks is too short to make consistent systems to build our game and make proper plans for development
  • It is important to focus in systems instead of small self-contained items
  • What you see and hear the most in-game, should be prioritized the most
    • Context here is that we shouldn't build extra assets before having the regular important assets like trees and stones.
  • At first more freedom and then slowly tighten the grip towards the end product.
    • As in art, broad strokes first
  • Serious games can be fun to make
    • But seriously they are harder than anything I've developed so far.
  • Applying for grants is hard, but getting the money is even harder.

Our team of students have been a really hard-working one. There were no people in the development team who'd disappear without a reason, even though this is a school project of 12 students. I love these people, and personally I have nothing bad to say about a single one of them. I'm proud of them, they've learned a lot and have been working both hard and smart to the best of their knowledge. I've done my best at that too. And in the end, we've all learned a lot.

I'm truly thankful for this experience, and hope that you enjoyed reading my collected thoughts through.If you have any questions about this project, feel free to comment. I might make a continuation post in the future.

Thanks to our team members at Lakes-12 and especially our playtesters and our Cognitive psychotherapist Kirsti Pyhäluoto-Keränen


Related Jobs

Square Enix Co., Ltd.
Square Enix Co., Ltd. — Tokyo, Japan
[06.02.20]

Experienced Game Developer
XSEED Games
XSEED Games — Torrance, California, United States
[06.02.20]

Localization Editor
Remedy Entertainment
Remedy Entertainment — Espoo, Finland
[05.29.20]

Development Director
Heart Machine
Heart Machine — Culver City, California, United States
[05.28.20]

Quality Assurance Manager





Loading Comments

loader image