I will be giving a presentation at GodotCon 2021 entitled, "(Almost) A Year of Fam Jams". The presentation will be a summary of how my family started doing game jams together and what we learned from the process. It draws liberally from my blog posts on the topic. The presentation is already recorded, and the conference organizers will set up a time that it streams, during which time I will be online to answer questions.
In preparing for the presentation, we had a family meeting in which I asked everyone what they learned over the past year and what advice they would give to someone who wanted to start fam jamming. This was an interesting exercise, and one thing that stood out to me was that some of them were happy to give advice that it wasn't clear they themselves had learned yet. "Do as I say, not as I do" is a powerful human capacity! I hope they understood when I pushed back on these points, because I wanted to make sure I distilled our true and best ideas for the presentation.
I took more notes from this meeting than I could fit into the presentation. This blog post gives me a chance to share my notes more exhaustively. I will start with the youngest family member and move up from there. I believe this order might be enjoyable and also demonstrate the differences in ability to form abstractions and conclusions. I have listed the items so that the first statement captures the essence of what the family member shared, and then I provide my commentary on that item after that.
#4 Son:
Put the game's name on the title screen. This was one of the first things anybody said in response to my question, and it made me laugh. He's right! We do always put the name on the title screen. Now, it's less clear to me that he understands the value of this in setting the expectations of the player or conveying the theme, but that will come.
Make sure everyone can work at the same time. That is, he recognizes that we don't want to be in a position where anyone is "busy-waiting", such as waiting for access to a particular machine or resource. Astute!
#3 Son:
Use the black keys when composing music. Readers may recall that this son is very interested in using LMMS to compose music for the games, and I showed him many months ago that he could avoid some dissonance by using only "the black keys" to get a pentatonic scale. He's latched on to that, and his compositions have been more ear-friendly for it.
Make the game's music match the theme of the game. This is a great observation, and I think it first came up in Get the Food. We definitely came back to this idea in other games, too, including Find the Ornaments, where we talked about what might make a song sound like the holidays. (Also, I don't think it only comes in games titled Verb the Noun, but more data may be required.)
#2 Son:
Have someone who can do everything that needs to be done. His point here is that you don't want to have three people who all want to write the music for the game and nobody who wants to do art. It's an interesting perspective, since I tend to think about it the other way: design the game such that it leverages the abilities and interests of the people involved. In fact, my wife brought up this point in response. Both sides are true, and I'm glad he brought it up.
Playtest with people who didn't program the game. He has noticed that if his older brother and I work on the programming, we might sometimes have blinders to things that are wrong or just feel bad. Again, this is a pretty astute observation. At first, I thought he meant people outside the family, but he really just meant that people inside the family should be giving feedback during the whole production process.
Leading does not mean you tell people what to do and wait until they are done: it means you check in with them and give them advice. This is an amazing point, and I remember that he struggled a bit with it the first time he was creative director. I think it was something like his telling other people to work and then his sitting down with a book. He got the idea, though, and we worked through it. Now, he is much better about communication, negotiation, and critiquing.
#1 Son:
Prototype the gameplay with blocks. That is, don't get caught up in producing and perfecting the minutiae before you get the big ideas working.
It's fun to make different kinds of games. I couldn't agree more!
This son also mentioned something that may seem pedestrian, but it's really not: how to use Godot Engine. He's become quite accomplished with it, to the point where he can navigate the documentation and forums and figure out pretty much anything he needs. Right now, he's looking into networked multiplayer games; we had a good talk about IP addresses on our family walk yesterday.
Lovely Wife:
Do drawings in pen or marker—not pencil—for ease of cropping and scanning. She has spent a lot of time post-processing the kids' hand-drawn artwork, and this is a nice, easy pro-tip.
Even though each game is different, there are certain things that you always need, such as fonts. I sometimes forget that, coming into it, my wife really had no idea how video games were made. That is, just because someone is smart and my age and played some video games doesn't actually mean they know what goes into the engineering of them. Now, she sees the patterns that I took for granted, like the idea that there are certain elements that you always expect to be on the to-do list.
We face challenges sharing workstations, and it's better to have each person have easy access to their own machine. She and I have tried to manage the proliferation of devices in the household, and we don't have a one-laptop-per-child policy. We have Old Lappy and New Lappy. Sometimes, this is not quite enough, and we're still trying to figure out the best way to manage all the technology needs and desires.
It is useful to follow genre conventions. Our first game was designed by a five-year-old and defies expectations, but after that, we moved more into conventional forms. This has been helpful for allowing everyone to imagine what the end product might be. It also has become easier as we have learned more about the tools themselves, since the tools are designed to help with common problems.
Determine your screen-size early. We had some mismatched expectations in our early jams about how to manage the size of screens, in part because the programmers saw this as flexible but the art production required it to be fixed. Now, we set the screen size early on, which means the prototype programming matches the expected final look, and the art comes in without needing to be resized multiple times.
Use drawing templates for young artists. As of The Flying Planes, we have been focused on trying to get more art into the games. In theory, this is simple: if we can put in one plane, then we can put in several. In practice, the kids drew them in all different shapes and sizes, which made it hard to get them all to fit and look right. Now, if we know something is to be mass-produced, she provides the kids with a rectangular template, which is really the bounding box. This makes it easier to scan and process as well as to integrate into the game itself.
Determine a palette early. This is a standard graphic design idea of course, though it's not something most kids (or maybe anyone?) thinks of. The games that have had constrained palettes are certainly easier on the eyes. Maybe this would be a fun area for us to grow with the kids, allowing them to explore palette creation and see how they affect the look and feel of the game.
No comments:
Post a Comment