1 free read left. Create a free account for unlimited reading + AI research.
Create free account[Music] time left hi so my name is Adriel Wallach and I'm an independent game developer I am best known for the organ breeding the organiser of a game jam that occurs on a train once a year as well as having made one new game every week for an entire year once and in this talk I'm gonna go into game a week what that project was why I did it what I learned from it and kind of more importantly what I didn't learn from it but before I delve into all that brief history of Who I am and how I got here I went to university and when I was graduate when I was don't want that and I graduated with my degree in engineering I didn't really know what I wanted to do so I spent a couple years working in like a big old company and writing code for something that would go into space eventually and after a while I decided that's not what I wanted to do and what I wanted to do is make games so I started teaching myself game development on the side attending local game developer meetups and networking with people from the industry and after
a few years of that you know I finally got hired as a programmer at a small indie studio in Boston in the States and while I was there as contracted out with Harmonix worked on their next rock band game which was Rock Band Blitz which is a rock band game nobody has ever heard of and once that project was over I moved over to a small contract studio I worked with bigger companies like Hasbro and the boss of Museum of Science to make sort of games for that and at that point after bouncing around and doing all that I realized that what I wanted to actually do was go full indie make my own games and do all that which after quitting my job I was super excited to start working on all those games that I had you know floating around in my head for many many years and I knew solo game development wasn't gonna be super easy but I figured you know I'd be able to take one of those great ideas got a prototype out in a couple weeks it's been a few months refining it have a great game within a year it turns out that I had never actually made a game by myself and doing all the non programming tasks was not super easy so I spent a few months procrastinating on all of that I invented train jams started that running
traveling around and generally just sort of avoiding making games and eventually I sort of had to face the fact that I was a good programmer and I'd worked on lots of projects but I had no idea how to actually make a game so a friend of she suggested to me to just make something make something in a week and then throw it out didn't matter what it was didn't matter if it was good didn't matter if it was bad just to make something so that I could make something and start gaining experience making things and eventually that would lead to making a good thing so that sort of where game a week came from and what I did when I started doing game a week was I solidified just a couple rules that I followed every single week and these are the main sort of constraints that I followed easy release a game every week for me that was Sundays I just sort of chose it arbitrarily I had to release the game every single week to the public I just sort of published it on my own website and that was super easy don't repeat ideas one of the points of this was just sort of vary my mechanics and my ideas as much as possible to get as much of a spread of ideas and then always write a post
mortem every single week explore what went right what went wrong and all the lessons that I learned from doing that game that week so I did those four things every single week for an entire year and by the end of it I learned a lot of lessons which you're all gonna hear about now a lot of the lessons that I learned from doing game a week came about as a natural progression of just repeating that same base task over and over again there's a story that gets told about a pottery teacher who splits her class into two she tells half the class that they have the entire semester to plan and design the best clay pot they can spend as much time and saying wounded and needed to plan that pot but at the end of the semester they had to submit that one clay pot that they designed the other half of the class got to design as many clay pots as they wanted and their grade was based on the quantity so they could sort of do you know refine or a finer refine at the end they also got to submit their best clay pot and the teacher would choose the best pot and long story short all the best pots came from the second half of the class where they did it over and over again and a story was sort of the
basis of game a week it's a good story to illustrate that the only really true way to learn how to do something is to just do it and do it over and over again and so a lot of the things that I'm going to go over might sort of seem super straightforward in hindsight but they're things that Gus solidified it for me over the weeks of repeating that same task of make a game and you know I've given talks on the lessons I've learned from game a week and you know I learned a lot of lessons but in the years since I finished game a week because I finish this back in 2015 I started spending a lot of time sort of thinking about weather game a week was good or was it bad did I burn myself out yes did I perpetuate a bunch of crunch culture yes did I do anything with any of those 52 games I made no is that bad I don't know so I just want to go through a lot of the lessons that I learned and I want to go through those major lessons and again talk about the things I didn't learn because everything sort of had a flip side obviously the most important lesson I learned was how to rapidly prototype I'm at a point now where if I have a basic idea for a game
I can just sort of bust out a working version in just a few hours and this is really great for when you're working on a new game and something that people sort of know me before and one of my like main selling points when I'm pitching for contract work you know I've gone through the act of starting a new project from scratching getting a concept up and working without much thought a bazillion times and because of that you know a lot of the projects that I work on get off to a really great and fast start however something that I've heard many people say over the years that games are never really finished you're just sort of done developing your game eventually just sort of stop it's true you know it's borderline impossible to make the exact game that you set out to make with all the features that you wanted with the budget you expected and at the release date that you were planning on and because of that there's very small difference between a finished game and an unfinished game it's just sort of this fuzzy line and every single one of my game a week games sort of hit all those major check boxes of what I would define as a finished game you know I released them to the public people could pay me for them I did a post-mortem all those sort of little check boxes but I'm not sure that I
would ever say any of the game a week games were finished games ultimately they're just unpolished prototypes that I put on my website that people could throw money at so even though I can start a game super fast I've never really learned how to finish a game when I think about how many games I've released in my career the answer is three and two of them are just very very small insignificant games you know there was that rock band game I was telling you about and two very small games a puzzle game called Condesa and a really small personal game called press X to be okay and that's sort of it even though I spent a whole year just making games over and over and over again that's fine we all know it's harder to finish a game than to start it but I think the bad thing that happened here was that I was so swept up in game a week and jamming and I never realized that I never learned how to make a game and take a project through polish you know how to add a credit screen or an options menu or all those things that we don't think about in that final 90% of game development was just sort of completely out of my scope of learning and it's impacted me a lot because my attention span for a project is now super short I have a hard time pushing any game further than a prototype on my
own because that's just not what I'm used to in the point of gaming week was for me to actually learn how to make games on my own and in retrospect it's something that game a week never could have taught me in the way that I structured it and then scope is that second major lesson that I learned from doing something like game a week I very quickly learned that every single game idea is too big doesn't matter whose idea is how large or small the team is creating the game or how much you think you've pared down your idea it's still too big forever and always and so every single week I would make sure to pair my ideas down to this tiniest sliver of a mechanic you know if I had two mechanics one we get thrown out if my idea even felt slightly too big I would just remove as much as I could a time that felt great and I know that it's a super important skill for game development but again I experienced that other side of the lesson by spending all this time just sort of focusing on producing games that contained exactly one small mechanic I never really refined my ability to put multiple mechanics together and it's rare that one mechanic can make an entirely commercially released game you know there's lots of games based on
one simple mechanic but the difference is that it gets sort of explored and expanded you know and you just sort of get to see different explorations of that mechanic and it's not really what I was doing at all I was making one mechanic work and abandoning it forever every single week which means that I was just sort of focusing on gimmicks instead of real games and because the time of constrain of game a week and the knowledge that would just be throwing it out there and never looking at it again I never really once explored the idea of you know multiple interacting mechanics my little games weren't games they were just sort of proof of concepts for a mechanic within the framing of a game and I never really once thought about the fact that I could take all of my weeks and sort of string them together I could take a mechanic from the week before put it in the mechanic that I wanted to do this week and just sort of explore that and ultimately that was sort of a really big huge detriment for the way I approached making games for a long time after game a week and it was something I actively had to unlearn over the next few years which I think I finally broke that habit and going on from that as I
said earlier every week I did a post-mortem where the idea came from what went right what went wrong in what I learned it sort of helped me organize my thoughts and see where my weak spots were which there were many and there were some weeks where I couldn't think of anything that went right and some weeks I couldn't think of anything that went wrong and you know in those weeks I tended to reach out to fellow game developers and friends to see you know what I did actually learn what I wasn't seeing because you know you can't make a game for a whole week and not learn anything that's impossible and as I was prepping this talk actually went back in read every post-mortem that I wrote throughout game a week and out of all the lessons I learned the lesson they learned the most was start my game earlier every week I wrote those words in one form or another in 19 of my 52 post-mortems which is roughly 37% of the weeks and it's not like I learned it a lot in the beginning and learned my lesson and learned it less later I just consistently through the whole year just kept learning that lesson and I think that sort of illustrates one of the
downfalls of how I approach to post-mortems for most part I would look at my game analyze how when go through all the motions of picking through my week write it all up put it out there but it wasn't until I read through all the post-mortems a couple weeks ago that I even looked at them ever again I never applied the lessons I was learning I thought I was because I wrote them up and you know that sounds like you're learning something but I just didn't like how many of you out there have written a post-mortem for a game how many of you have read that post-mortem ever again two of you good job and I mean like six months later not just like immediately later like a significant amount of time later anybody know okay and yeah that was one of those things for me a lot of my lack of actually applying the insights came from the fast-paced nature of game a week you know there was barely any breathing room week a week and it wasn't till after game one week ended that I was really able to catch my breath and take a break
but by then it was so burned out on the concept of game a week that I need wanna look at it again I didn't want to think about games I didn't want to look at any of the prototypes or read any of the post-mortems and you know I just sort of never did it again I think that's something super common and a lot of projects in game development like not just things like game a week and short jams but large projects come with that era of just wanting to be done with it the last times that they say like the last 10% is 90% of the work which if you think about the first part of what I said where you know 90% of game development is out of the scope of game a week game what we've taught me basically nothing that's just how math works so yeah the lesson here is make time after your projects to River do or absorb the lessons that you actually did learn go read your old horse more terms it'll probably be more helpful than you're thinking and when I was you know the most practical lesson that I learned obviously from something like game a week was deadlines for 52 weeks I hit a deadline of releasing something every week when you think about it's kind of cool to be fair there were six weeks
where I didn't release a game but you know still I went through the post-mortem of weeks that I didn't even make a game and I sort of wanted to go through what wouldn't right and what went wrong so I still released something and though hitting a schedule is obviously incredibly important the rigidity of how I structured game a week in my mind let me do never considering the fact that I could just extend a deadline I just sort of worked myself to the bone to do the deadline every week and it's one of those game production skills the game a week unfortunately kept me from learning the fact that sometimes projects just need to be delayed to be the best that they can be you know I pushed myself hard week to week and mentally beat myself up every time I had to skip a week and you know as being my own worst producer and at something I think everybody should just be aware of as deadlines are cool at all we should all hit them but sometimes they just have to go away you just need to breathe who I'm running out of time so to wrap this up in a bit I want to talk about what I think were the two biggest things that I took away personally from spending an entire year making one new game every week the first
being that it really helped me transition into being comfortable being a creative until I started game a week I was a tech person I was an engineer and a programmer I worked in an office all day and I was always sort of the tech person that's how I grew up I always loved tech whatever but I knew that I had this more creative side to myself that I just wasn't sure how to get to and that's sort of the number one reason why I left the Space Systems industry and came to games as there's not really any creative freedom when you're working on a twelve billion dollar thing you're gonna strap to a rocket and shoot into space rightfully so that was cool but that's not what I wondered I didn't want to spend weeks on end making sure that my code adhered to NASA standards and I wanted to make things that allowed me to show off this weird little creative monster that was rolling around in my head but once I transitioned a game I still needed to get out of that tech shell that I was in they had to put myself out there to really figure out how to make games instead of just being a games programmer which is a subtle sounding difference but it was big to me and being able to figure out if making games something I could do or anything I actually even wanted to do so that was a
cool exploration there and the second one of these two big things that I learned was simple and much more generally applicable is that burnout sucks I spent an entire year jamming like really let that sink in how tired are you after a weekend of jamming how tired are you after crunching extend that jam to a week and extend that crunch to a year it was awful I was constantly working I was constantly switching my brain to a new project I was constantly coming up with ideas and I was constantly sort of just making and releasing a game I was always working really late in the night on the weekends just sort of making things over and over again and I did that for a whole freaking year and at the end of that I was super burnt out I didn't work on anything else for months because I couldn't bring myself to turn my brain back on after actually giving it a real break and went to this whole being completely lost creatively and it took me a really long time to pull out of it it was probably another year until I worked on something of my own again and I've gotten a lot better since game a
week about taking breaks and started actually tracking my time on projects and scheduling you know like one day a week where I'm not working I mean it's something that I thought just had to happen in order to become a creative person everyone crunches everyone works too hard you know all those good myths and it's one of the reasons why I become super wary of ever suggesting something like game a week to anyone anymore or even a jam because you know jams have gotten so prevalent in the games industry and country culture is so insidious do I really want to be adding to that do I really want to you know say that spending an entire you're jamming and burning yourself is great and I don't think I have an answer to that best I can do is just sort of say what I experienced and let people figure out their own stuff it's just weird I organize one of the biggest jams in the world and I'm like man yeah that's sort of my big long fast rambling thing here and to sort of summarize what I've been trying to say through this whole talk it's not a thing that teaches you something doesn't necessarily teach you something else is sort of the big takeaway here almost every lesson I talked about had a
corresponding thing I didn't learn and was detrimental for you know for the rapid prototyping is that I never learned how to do game production for scope it was that I never learned how to make things work together you know for critically analyzing my own process it was just that I didn't have any structure to internalize those lessons and I think these specific things are all super important to think about but to extrapolate it even further what I'm trying to say is that I feel it's really important to make sure that you're looking into the spaces of what you're doing and that's sort of the whole summary of this talk figured out what it is you're passively missing what you're not learning and what you're not improving on just by the very nature of the sort of learning not learning duality that I just made up and make sure you're approaching your process with a critical eye and taking the time and care to take a step back okay that was it a lot of words I seventeen seconds to spare I think we had already said that we were trying to compress the talk like a small time anyway and I was gonna let you run over so some questions cuz I
know Barry's here but she's a little bit behind so were good question there from here thanks for the talk yes sorry what's it almost so if I understood correctly you made fifty two prototypes out of which four to six were released yeah so what's there wasn't there any of those prototypes such that you would have wanted to pursue further and actually make into a polished product there were a few and there's one that I actually like just picked up a couple weeks ago to be like yeah I should release this on like iOS just real quickly I think the big problem was like I said once I was done with game a week I was so burnt out that I didn't want to look at anything that had to do with game a week ever again and so I sort of just put it into this folder and I didn't look at it for a long time and then you have it is when you lose momentum on a project and you're just like oh well I'll never do that again and then also since I'd focused a whole year on that my savings head around outside to pick up contract work and bla bla bla bla bla and it's sort of
spiraled out of there but there are ones that I would like to do something with I just haven't but I learned the lessons will you're probably at some point go back to one of those yeah I'd like to I always joke that I think it would have been really cool and I might still do this someday is like pick four of my favorite ones and do polish and production a quarter which has way less of a catchy title but we'd still be really cool to just spend like three months on four different ones of them and try and get them going it's something that's been in my mind in one of these days I might do it but I have no solid plans right now it feels like you know that kind of might my career of basically having to run services for like 20 years yeah that's our the absolute antithesis what you've done and I mean literally it's like having how do you make this thing that's already been done work yeah you know it's a it's a nightmare but it's completely and again all all the opposite lessons that you've described about crisis it's making sure you don't do crunch because you yeah cause you've got to still be doing so with our powers combined yeah we will
take everything of us well I mean come jokey but I think there is something about what would that formula be yeah would you teach yourself for other people how to do that sustained delivery the deals our knowledge I don't think there's a way to do it but I think is interesting yeah because I just carry on talking oh boy there's one that hi thanks for the interesting talk so I just had one question are you now more creative after the game am weak thing am i more what creative I think so I mean it definitely gave me a crash course unlike what other things are involved in games other than just programming all those things that I knew existed I just had never tried them before I think I have a lot better feel for where my strengths and weaknesses lie in terms of creativity so I don't know if that makes me more creative per se or just more
knowledgeable about what's inside of me and that sort of like fluffy kind of way I feel it was a net positive in terms of my game development processes I guess is my answer to that and sadly I I know there's few more people want to ask questions but we'll have to call it time thank you so much that was fantastic [Applause] [Music]
Adriel Wallick, an independent game developer and organizer of the annual Train Jam, reflects on a year-long project in which she developed and released one game every week. The primary objective of this initiative was to transition from a technical engineering background into a creative role by rapidly building and releasing 52 distinct game prototypes. The project was governed by strict constraints: a weekly release schedule, a prohibition on repeating ideas, and the requirement to write a post-mortem analysis for every game.
The experience yielded significant professional growth, particularly in rapid prototyping. Wallick developed the ability to conceptualize and build functional game mechanics in a matter of hours, a skill that proved highly valuable for subsequent contract work. However, the project also highlighted a critical "learning duality," where the focus on rapid iteration came at the expense of long-term production skills. By treating every game as a disposable prototype, she failed to learn how to polish a project, manage complex systems, or navigate the final stages of game development, such as implementing menus or credit screens.
The project also served as a cautionary tale regarding industry burnout and the normalization of "crunch culture." The relentless pace of the year-long cycle led to severe creative exhaustion, resulting in a multi-year period where she struggled to engage with game development. Wallick concludes that while the project successfully helped her identify her creative strengths and weaknesses, it also underscored the necessity of sustainable development practices. She emphasizes that developers must critically evaluate their processes to identify what they are failing to learn, noting that the most effective way to improve is to balance rapid experimentation with the deliberate, often overlooked, work of refining and finishing a product.
Comments