Starting market research for your game

         I am doing a podcast with my friends about games (check out The Adventure Mechanics here) and I decided that I need to try for accountability on actually releasing a game. To that end, I'm going to go through the development process to release a game. Here is the transcript from the seventeenth episode on starting market research for your game:

Hello and welcome to The Adventure Mechanics, this is another side quest.  I'm Chandler.  Today I wanted to talk about doing market research for your game.  I know it's not the sexiest thing, but it will mean the difference between your game being moderately successful and an utter failure.  After all, there are thousands of games being made right now and I'm willing to bet that you don't know about the vast majority of them.  Let's talk about doing your research before diving into that next game design, so you don't end up disappointed when it comes to release.

So, how do you do market research?  It starts with knowing what your game is.  Are you making a puzzle-based metroidvania?  Then you should look at both puzzle games and metroidvanias.  Is your game harder to define the genre for?  Then you'll want to spend time nailing down what, exactly, genre your game falls under.  You want to make sure that you are casting your net to be as broad as possible at this point to cover the most potential audience that you can.  Why do it this way?  Because it gives you most optimistic picture as you go about defining your audience.  And that's important because if your game is requiring a certain number of people, and your market research says that your audience is smaller than that, it's a pretty good indicator that you shouldn't be building your game.  At least not in the way that you have it currently.

That's not to say that you should define your game so broadly that you're not going to get useful information out of research for it.  If your game falls into the genre of survival crafting, for instance, try to narrow it down a little bit further.  Yes, there are a lot of games that fit that genre, but you're not going to get a whole lot of useful information out of your research if your delta is so large that it can be anywhere from zero to infinity in terms of audience.  In the instance of survival crafting, think about what theme you have for it.  Is this an environmentalist survival crafting game?  Then include the environmentalist tag in your search.  Is it zombie themed?  Put that zombie tag in your game search.  The idea is to get as many tags that can apply to your game as possible and still properly define it.  Once you have that, then we can move on to the next step.

The next step being looking at other games with the same tags and seeing how they perform.  You can use resources like steam spy or steam charts if you're planning on making a PC game and releasing it on steam.  Note the top selling games from your search results and note their sales numbers.  This is going to be your market ceiling.  Also, if you can, take a look at the average price of the game and use that to estimate about how much that game has made.  It's not going to be a perfect number, but that will give you at least a general idea of what a breakout game can make when it's similarly tagged.  This is how much you would potentially, and I stress potentially, make if your game happens to repeat that same lightning in a bottle.

Don't just look at the top performing games, however.  Likely your game is not going to be the breakout hit that you're hoping it will be.  It would be nice if it was, but statistically speaking it's not going to live up to your expectations.  Look down at the mid and a few of the bottom tier games that match all of your tags, or most of your tags.  Do the same calculations with these games, too.  This will give you the medium and low range for what a game in your genre could potentially make.  Obviously, the floor for any game sales could potentially be zero, but hopefully you're putting enough effort into it to at least make a few sales.

These games are also useful for looking at for other reasons.  They will be more informative of your likely audience.  People who buy these games are looking for your game, specifically.  This is where you'll find feedback on what your audience enjoys about the genre or similarly tagged games and what they don't like about them.  You can use these pieces of information to inform your game design.  Did you plan on copying something that one of these games already implemented?  If yes, what did the audience say about it?  Was it positive, negative, neutral?  Use that information to guide your decision making.  Remember, all of this is to reach your goal of making a successful game, however you define successful.

Let's use Cartogratour as an example here.  The most successful game as a reference point I can use would be stardew valley.  That game has a huge audience and countless fans.  It's also a farming simulator, not a cartography game.  That means it's not going to be the best reference point for what I'm making.  What other games come to mind?  Well, taking a look at the steam charts for casual sim games isn't really going to help me.  I could put pixel art and map in as tags, and that might actually help narrow down other games that match it.  I kind of already know a moderately successful game that matches Cartogratour better, though.  It's a game called Carto.  Carto is a much better reference point, since it also focuses on cartography as one of the main mechanics and will likely have more audience in common with mine.

Let's take a quick look at the steam spy estimates for Carto.  The list price for it is $20.  The range of people who own it on steam is between 200,000 and 500,000.  That's a lot.  And a wide range as well.  This is probably going to be my top performing reference point.  To get a rough estimate of how much they made from selling this game on steam will half the price of the list price, because nobody buys a game full price, and multiply that by the lowest bound and highest bound.  That gets us between $2,000,000 and $5,000,000 in sales.  That seems like a pretty high upper bound, honestly.  Far more than I would expect, or dream of, Cartogratour to make. Keep in mind that number is not the end profit they made off the game, but rather the raw funds they will get.  Steam has a thirty percent fee for the average game, which means that two to five million figure is cut down to 1.4 to 3.5 million, to say nothing of game returns and other issues. It's not strictly relevant, but I wanted to mention it nonetheless.

Now that we have the upper bound of our research, let's narrow down the tags that we can use to find other game options that would match Cartogratour.  I'm going to choose five that I think will attract the most audience to my game: Exploration, Casual, Indie, Relaxing and Adventure.  This covers the vast majority of the features that I would use to describe my game. When I searched Steam in preparation for this talk, these tags narrowed the results from the absolute firehose on Steam down to 47 games.  That's a lot more manageable.  There are a number of irrelevant games in the results (I'm looking at you, Euro Truck Simulator), so I can't really use those.  So, to narrow it down further, I'm going to eliminate games released in the last month, along with games that have over a thousand reviews or less than one hundred.  When I did this, the results matched better the games that I see Cartogratour competing with.  I ended up with the following three games: Teacup by Smarto Club released in 2021, Miner: Dig Deep by Substance Games released in 2020 and Time on Frog Island by Half Past Yellow released in 2022.  When I do the same analysis on these games, I get the following: Teacup: $0-$100,000, Miner: Dig Deep: $0-$90,000, Time on Frog Island: $0-$200,000.  All of these titles have anywhere between no and 20,000 owners for the game estimated on Steam.  I took a quick look at the titles on steamcharts and this seems reasonable to me.  If I release Cartogratour on Steam, I now have at least a rough idea of what I can potentially expect in terms of income.

So, what does that mean for Cartogratour?  If I wanted to release it on Steam, I can only reasonably expect roughly $60,000 to $140,000 over the next two years.  That may sound like a lot, but if I have to solely rely on that to fund my next game, that only gives me a short runway.  I need to be able to keep my next game to less than a year of development to just make it.  It's not a rosy picture, but that's game development, I suppose.  This is why you want to take a look at the existing games, both the blockbusters and less successful ones, to see what to expect.  Sometimes your game just won't have the audience needed to keep you in business.  It's that information that you need if you plan on having game development be your main job, or not.  Like all information, it's up to you to decide what to do after getting it.  For me, knowing this basic market research, it's not going to stop development on Cartogratour.  I'm not necessarily building it to make money.  I'm making Cartogratour to scratch an itch for game design, and that's enough for me.

Whew!  That was a lot, wasn't it?  And that's not even the really crunchy parts of market research that you may end up doing.  I'm not going to go through these three games and their reviews today.  I know I mentioned that it's an important part of market research, and it is, but I don't want to overload this side quest just to fit it in.  I may do a second side quest on breaking down reviews specifically in the future.  If that sounds interesting to you, let me know!  I want to make side quests that are useful for others as well as myself.  Needless to say, but I'm not an expert in the field, only a solo developer looking at the potential market for one of my games.  Take anything I'm saying with a grain of salt.  As always, if you have any comments, questions or suggestions, reach out to me on either Twitter as @jcsirron or in the comments section of this episode.  This has been another side quest for the Adventure Mechanics and I'm Chandler.  I'll talk to you next time.

Getting Started in Game Development

         I am doing a podcast with my friends about games (check out The Adventure Mechanics here) and I decided that I need to try for accountability on actually releasing a game. To that end, I'm going to go through the development process to release a game. Here is the transcript from the sixteenth episode on starting out your game design journey:

 Welcome to another episode of the Adventure Mechanics side quest.  It's me, Chandler.  Today, I want to talk about where to get started in game design.  I have been asked that question regularly, especially from people that are either new or intimidated by the idea of developing a game.  And it is a lot to consider.  Every aspect of your game must be considered and contemplated.  You need to be at least competent enough with your prefered language, engine, or whichever tool you have decided to use to make your game.  It's almost impossible to know where to start.  There's as many answers to this question as there are developers, but I think there's a common thread in each, beyond survivior bias.  Let's talk about some of the things you should consider when starting your game development journey.

The first questions I usually hear when someone asks about how to get into game design is, "what engine should I use?"  or, "what language is best for game development?" as if there is one single answer to these.  Simply put, these questions don't matter yet.  What is your goal for your game designs?  That's where you really should start.  Once you know what your goal is, then you can start answering the earlier questions.  If you have prior programming, art or music experience, these will also inform your answer.  Have you been exposed to a specific programming or scripting language that you're comfortable with?  Use that.  It doesn't have to be the most performant, the cleanest or prettiest language, or anything else that some newer developers will rail on about.  As a new developer, you should be more concerned about how to design a game, not losing yourself in the weeds of comparing performance benchmarks of engines or languages.  If you find yourself comparing how fast one engine does a loop over another before you have released your first game, you're not prioritizing your game.  Don't get me wrong, your first game is going to have to use something, even if it ends up being cardstock.  But fixating on tiny details and pursuing perfection over finishing your game will mean you aren't likely to finish your first game.  Accept that your first game is not going to be perfect and use it as your first step into the discipline, not the start of your magnum opus.  Of all the successful Chris Roberts types that end up in the industry, there are legions of people that pursued perfection at the cost of the good of their game and have not released their game as a result.  In the worst cases, they aren't developing games at all anymore.  I don't want more people to drop game design from this common trap.  Explore why you want to make games before you start searching for the tools to use to make it.  Just as RPG maker will be the absolutely wrong tool to make a first person shooter, using a specialized tool can hinder you as much as not knowing how to design.  That being said, if you end up opting for a general purpose engine, make sure that it has the support or tutorials that you will need to succeed on your first game.  The most powerful engine is useless when you don't know how to use it.

So, assuming you've figured out what to use based on your existing skillset, what type of game should you make?  To answer that, answer this question: What games are you interested in?  If your first answer is and MMO, which part of that MMO interests you the most?  Is it the combat, the social interactions or something else?  Most importantly, can you make an entire game around that one part of MMOs you enjoy the most?  As your first project, you need to make it as small as possible.  And building a fully featured MMO to rival what you played on Battle.net isn't small.  You're learning the basics of game design, so pulling from existing designs and focusing on it will help you learn why things you enjoy were designed that way.  If you adore your favorite game because of the world and everything in it and nothing specific, then look at other short games you've played and pull from them.  You need to be able to pull out one thing that you consider could be made into a complete game and work on that.  For me, it ended up being bullet-hell games.  I made a bullet-hell style game that didn't even have bullets.  Strange, I know, but from my prototype, Log Jam!, I learned a lot about designing games.  I never ended up releasing that game, but taking a game from start to end really opened my eyes.  It sparked a passion for designing games that I've been eager to share with others.  I'm not a fan of bullet-hell style games in general, but it was simple enough to copy and finish.

My experience brings up another important thing about your first game.  Finish it.  It may sound silly, but going through the whole process really will teach you so much more than having a stack of prototypes on your proverbial shelf.  The beginning of game design is intoxicating.  You're working fast on something new and interesting.  Everything you add to your game is making a huge impact.  Once you have gotten past that stage, though, the game changes aren't nearly as impactful.  Does this UI look better over the last one?  Maybe?  How could this card read to color blind players?  These type of questions are what you're going to be working through as you transition from prototype to polishing.  This part is just as import to go through as the prototyping phase.  Sure, it's not as fun, but this phase of game design is going to teach you so much more than exploring basic mechanics in prototyping.  How you set up a menu, how to make your game "feel" better, even how to get useful feedback from playtesters comes from this later polishing stage.  This is where you take your game from an interesting concept to a great game.  In earlier talks, I refer to this time as being in production.  You're not coming up with new ideas, necessarily, rather you are working with the building blocks you placed in the prototyping phase and finding ways to showcase the core mechanics you've come up with.  This is where you can really show the interesting parts of what you have and not just putting everything in place so you get a rough idea of what the game is.  The more time you spend in this phase, the better the game you eventually finish will be.

But what does a "finished" game mean?  That's for you to find out.  For some, it's when you can't think of anything else to polish and work on.  For others, it's when you're so sick of your game you almost want to delete it in disgust.  If you feel like this, by the way, just walk away from it.  Don't delete it.  And in some cases, it can become an evergreen project, where you can always add something to it to make it more engaging.  I'm sure you can think a game like this: A game that is seemingly always in early alpha and never seems to get to that coveted 1.0 release.  Whatever camp your first game ends up in, commit to an end point.  It can be as formal as you wish, be it finishing a road map, or as simple as a date.  Hold yourself to this and when you reach that end point, set it down.  It may not be the best feeling to leave your work like that, but it's important to hold yourself to it.  Listen to my talk on accountability on why that particular point is important.  Or, if that doesn't work for you, look at what you consider a finished game.  Then apply that criteria to your game. If you find that you've already passed that criteria, odds are you're already done with your game.  Knowing when to quit is one of the harder things to learn, especially when you're working on a passion project or artwork.  Yes.  I do consider that games can be artwork, although that's a talk for another side quest.

There's a whole lot more advice that I could give in terms of getting started in game development, but I'm going to call it here for now.  It's best that I don't end up repeating myself, after all.  As always, if you have questions or have a comment on this podcast, let me know.  You can post it on our website www.theadventuremechanics.com or to me directly on twitter with my handle @jcsirron.  This has been the adventure mechanics and I'm Chandler.  I'll talk to you next time.

Momentum

     I am doing a podcast with my friends about games (check out The Adventure Mechanics here) and I decided that I need to try for accountability on actually releasing a game this year. To that end, I'm going to go through the development process to release a game. Here is the transcript from the twelfth episode on momentum and how to keep it going for a project:

Welcome to the adventure mechanics side quest and it's me, Chandler. With the holidays in the rear view mirror, I've come up against this unenviable situation: I've been officially working on CartograTour for over a year. Sure, I haven't worked on it as much as if it was my day job, but I still haven't gotten nearly enough of it done. I've taken a look at my version control history, and, I've got to say: it's a sorry sight. There are periods of manic pushes coupled with rather large swaths of... Well, nothing. Some of those lulls were due to personal issues, but most were due to lack of inspiration. I had trouble refining the main gameplay loop in my head for quite some time. I have only recently come up with other things for the player to do that fit diegetically. With those last pieces in place, I think I have a relatively good foundation to start executing on the game. Artwork continues to be a struggle for me and sound design hasn't even come up, yet. That being said, those things aren't something I had to focus on quite yet. But now the project is now to the point where coming up with ideas is finally ending and it's time for me to look at something I haven't really done for a game: production. For today's side quest I'm going to talk about production and keeping momentum going on a project.


Now, I know I just did a side quest on motivation and you may wonder why I'm talking about momentum. They're roughly similar in terms of goals and results, so why focus on something so close to it? Well, honestly, it's because of the difference between the two: motivation is about starting, momentum is about continuing. That is one step closer to the end product, after all. More importantly, that's what you need for production. All of it is in service of that end goal; getting the game out the door and into your hands. Motivation is the micro issue every day, momentum is the issue for every update. I'm not going to be obtuse and say it's a macro issue, but it is certainly an issue. Without momentum, you can easily get stuck in "the swamps" of game design. And, oh boy, you do not want to get stuck there. Trust me.


First, let me clarify what "the swamps" of game design actually are. They are the time between first prototype and final polishing. That time where you're not quite sure the design is actually fun. You're in production, yes, but you're not done with tooling up, yet. These are times where momentum is absolutely sucked from you. The swamps may be short, or they may take a long time. Bioware programmer and producer Mark Darrah somewhat loathingly describes the end of the swamps as "Bioware Magic." This is that magic point where productivity shoots through the roof and the roadmap to finish the game finally hits something more realistic than finishing a decade from now. Now, to be clear, that typing point is also a sign of crunch in a team and I highly recommend listening to his reasoning why you shouldn't use the term "Bioware Magic" at all, but that's not really why I brought it up. It's more so because of that time before suddenly becoming more productive. The times where you're struggling to find the fun in the game, to get the real core of what the game you are developing should be. Time in the swamp can be short, or it can be years. How can you avoid, or at the very least minimize it? Keeping momentum.


Keeping momentum going in your project is rough. If you need any proof, take a look at any dev log for an eventually abandoned game on YouTube. Solo devs spend a year (or more?) on a single project, only to end up abandoning it later. They may lose motivation, they may have a life event that prevents them from developing further. Whatever the reason, though, their game is left only visible in dev log videos, a stark reminder of what could have been. Now, some of these games were appropriately abandoned, others, not so much. One thing that is common to most of the projects I see is that the developer tends to spend more time producing the dev log updates than actually working on their project. That’s certainly not true with all projects, but enough of them want to talk about their game and produce “sizzle reels” over actually getting the game done. After all, time spent on producing other things can take away from the project itself. Sometimes you need to walk away from it and come back with a fresh mind, but if you’re working on a consumable related to the game that isn’t in service to the end goal, you really are taking away from it. *cough* I’m looking at you, Chandler… *cough*


So, how can you avoid that fate and keep on track? Well, in perfect honesty, I’m probably not a good role model to look at. That doesn’t mean that I don’t know what's necessary to get a project done, though. Small wins are key. They are the things that you look back at and point at that you completed, or are really proud of. That doesn't mean amazing artwork or a really appropriate soundtrack or sound effect, either. It's making the main menu, the options screen, all the small things that make a game complete. Sure, there may be some days where you look back at what you've worked on and not really be able to point at anything, but you need to keep those days to a minimum. Even if it's a tiny improvement, completing that one feature or even tweaking it to feel better will keep momentum going. In the game forum I'm part of, we have a saying, "no zero weeks." The real quote is, "no zero days," but most of the forum goers have day jobs and family and can't necessarily work on our game designs every day, hence why we changed it to weeks. The point still stands, though. If you want to get a game done, you need to put in the time to finish it. It will never get done if you don't put in the time. And for me, at least, that means having small wins every time I sit down to work on Cartogratour. That little bit of dopamine keeps me wanting to come back to work on it.


That's not to say that's the only way to keep momentum. Another way to keep momentum is to have some form of accountability. It may be something you announce publicly, or to yourself, but having accountability will force you to have someone, or some time to be done with your game. I know I literally just railed against devs that did it and quit, but dev journals can be one method of making yourself accountable. I personally don't find them to be really motivating, since your accountability is more nebulous than having a friend that can take you to task when you're not done when you say you were supposed to be. A public dev journal does provide some sort of accountability, though. If that's going to be enough for you to get your game done, do it. Personally, I need something more to keep myself on task, though. As I said earlier, I am part of a game development forum. Part of that is updating everyone on what you've done over the last week. It's not a whole lot more, but having to say that you haven't gotten much, or anything, done on your project does give a tiny bit of a guilt trip to keep making progress on it. So far, that has actually kept me working on a game design longer than when I didn't have the forum for accountability. Having to update a group on a regular interval is what helps me the most in terms of keeping accountability.


Whatever you use to keep accountability, make sure that you're not losing the end goal of having it in the first place: Getting the game out the door is the first priority. If you no longer are getting value from one form of accountability, jettison it. If the accountability isn't helping you get closer to your goal, change it's form or ditch it entirely. Accountability is only as good a motivator as you allow it to be. If that accountability changes to something else and becomes another hobby or whatever, make sure to find a replacement. Most importantly, if you don't get motivation from the accountability, don't spend time trying to conjure it. Switch to a different strategy that works for you.


On that note, one last way to keep momentum is to make a timeline, or set a short term goal for what needs to get done. In more formal company environments, I would be advocating for scrum or sprints. In this case, I'm advocating to chunking out the work into as small of pieces as possible to get the game done. It's not sexy, or even interesting for that matter, but it works. Small pieces are just easier to finish over getting something huge done. That ties into my first method, go for the small wins. Having small pieces planned out can prepare for just that situation. I may not like mixing work and my hobby, but this is genuinely one thing I have pulled from my professional life into my personal life that helps me. The important thing is to not plan out everything in such detail that you feel like it's "just executing" on it to finish the game. Things change in design and when they do, you'll be throwing away that effort that you put into the later parts of the plan that are no longer relevant. And that's just wasting effort that can be put towards the game itself. So, plan in smaller chunks and get those parts done. Then repeat that cycle as many times as needed. And if you find yourself getting overwhelmed by the pieces you've made, it's a good sign that you aren't done breaking apart your work. I'm currently in the throes of doing exactly this to Cartogratour. I'll make another update for that when I'm done planning it out, though.


That's about all that I have for this side quest. Hopefully you find it entertaining, if not enlightening. As always, if you have any questions, ideas or comments, reach out to me on Twitter. My handle is @jcsirron. I will talk to you next time.

The Dreaded Crunch

    I am doing a podcast with my friends about games (check out The Adventure Mechanics here) and I decided that I need to try for accountability on actually releasing a game this year. To that end, I'm going to go through the development process to release a game. Here is the transcript from the eleventh episode on crunch and how it damages a project:

Welcome to the Adventure Mechanics Side Quest.  I'm Chandler.  I haven't been able to get much done on Cartogratour over the last month and a half, and it's not due to lack of passion on my part.  Over the that last chunk of time, I have been knee-deep in work crunch, for a variety of reasons.  With work taking up all my spare time and creative energy, little has been left for game development. Instead of just complaining about my latest foray into crunch and how unfair it is, I'm going to go over why crunch is bad, and not just from the perspective of the people going through it.

I'm sure you've heard about crunch, but what do I mean when I say crunch?  Well, crunch is an intensive effort over an extended period on a given project.  That means that you could be crunching on a project that you're only dedicating some time per week on.  In most cases, though, it's typically associated with working inordinate hours on something, often to the detriment of work/life balance.  Crunch means that you're working harder and longer on a project than you can comfortably accomodate.

Now let's talk the human cost of crunch-time.  When you're crunching, you're not taking care of yourself as well as you do when you aren't crunching on a project.  That dentist appointment?  You don't have time for that, you're crunching.  Need to workout?  Tough, you're either working while working out, or you're just not going to have time to work out.  This push to get the project, or thing, or whatever, requires you to set aside other things in your life to get closer to that finish line.  That's not only going to be a cost you'll have to pay later, but it may also be something that you'll have to pay during crunch, anyhow.  Crunch will end up just wearing down everyone working on the project.  And with people worn down, quality will suffer.

Why do I say quality will suffer?  Well, I've been subjected to crunch twice this year alone (thank you poor management!) and I have seen what work "quality" comes out of crunch.  It's frankly subpar.  Now, I'm not throwing my coworkers under the bus, far from it.  I am just gauging their output.  Sure, the first week is okay, but the longer the crunch drags on, the worse the code becomes when it eventually gets checked in.  And I do mean eventually.  On a normal, non-crunch day, my team can commit multiple times, no sweat.  During a crunch, though, some days may be commit-free.  To be fair, that may be because of things beyond their control, such as a poorly defined tickets or ones that are ginormous.  On the other hand, those also indicate that the project wasn't well defined before setting the team loose on it.  Worse yet, it sets up the team for failure.  A poorly planned project will absolutely waste precious time and end up delaying the project, despite how much project planners may argue to the contrary.  As the old addage goes, failure to plan is planning to fail.

But let's say that the project was planned out in a sane fashion.  Enough time was alloted, at least according to initial estimates.  One delay leads to another, and you're staring down crunch again to get back on track.  This may be tempting, but the initial crunch to get back on track will more often lead to burnt out people and, paradoxically, less work done per hour put into the project going forward.  Moreover, when a person gets burnt out from crunch, it takes more time for them to recover from the crunch itself.  It depends from person to person, but from what I've seen, crunch may be linear, but recovery time is geometric.  What do I mean by this?  For each day someone is crunched to burnout, you'll need to double the number of days needed for recovery.  That doesn't mean that they'll necessarily need to completely off work, but they'll need a lower workload to take care of themselves and have time to reset.  If crunch happens too often, then the team will begin losing expertise and members.  That shouldn't be worth it, but I know some managers are willing to make that sacrifice to the team to get a project done.  Thankfully for me, I haven't been in that situation.  Losing team members to crunch, especially during crunch time, is a recipe for disaster.  The crunch effectively becomes a dreaded death march.

If you're not familiar with the term, I envy you.  A death march is when most people, if not everyone, is crunching for months on end.  The team may be smaller from attrition, but new people aren't brought on to replace the losses, since that would take even more talent away from the project to bring them up to speed.  So everyone just crunches a bit more to make up for the losses incurred by crunching.  Obviously this isn't a good place to be.  Bugs normally caught, handled and resolved are passed by or, worse yet, allowed to persist in the product.  There's simply not enough time to resolve them and continue to add new features, at least that's the perception.  Those external pressures aren't going away any times soon, so why not let those relatively benign bugs through and tackle them after release?  Nevermind the fact that these bugs will damage sales in the first place.  Needless to say, but once a project is in a death march, it's only a matter of time before a collapse.  It's only a question of whether the project finishes or the team breaks first.

What I've said so far could apply to any software project.  What makes making games unique?  The culture.  Everyone is hyped to high heavens for the upcoming game and want it NOW.  Management sees the dollars slipping by the longer it takes to push out that new game, so they're pushing as hard as possible on the developers to get it done.  They claim that overtime isn't required, but if you're a contractor on a game and don't do overtime, you're not likely to have your contract renewed.  This leads to an extremely unenviable position of crunch or get fired.  Talk about stressful.  That speaks volume to both the concept of contractors and salaries, but I digress.  Numerous exposes have come out over the last couple of years about crunch and how it ends up sucking the souls out of teams and leads to some extremely toxic situations to work in.  Despite the exposure to this, we as gamers still demand to have games ever sooner with more and more polish.  We are part of the vicious cycle of crunch and death marches at game studios.  I'm not putting myself above this, either.  I'd be remiss if I said that I didn't get antsy when a game I was looking forward to was delayed.  One thing to keep in mind when a studio announces a delay, though, is that it's giving the team behind it time to put on the finishing touches on their game.  I know the Miyamoto quote, "A delayed game is eventually good, a bad game is bad forever," no longer really applies in our current world of massive day one patches and "evergreen" games, but at the same time, giving a game time to put it's best foot forward is important.

Obviously I'm still a bit salty about having to go through crunch yet again this year.  Hopefully I've given you insight on what crunch is, why it's a problem and why patience is going to make up for getting what you want a bit later.  As always, if you have any questions, comments or suggestions, reach out on twitter.  My handle is @jcsirron.  This has been the Adventure Mechanics Side Quest, and I'm Chandler.  I'll talk with you next time.

Looking at Motivation

   I am doing a podcast with my friends about games (check out The Adventure Mechanics here) and I decided that I need to try for accountability on actually releasing a game this year. To that end, I'm going to go through the development process to release a game. Here is the transcript from the tenth episode on examining motivation and my development as a designer:

  Welcome to The Adventure Mechanics side quest and it's just me, Chandler. When I first started getting serious about game development, I created a blog as a way to write down my musings and spread my interest and game design with people. Looking back at it, one of the first posts I made was about motivation and completing a solo project. At this point, I was mostly working on game jam games. I feel like I need to readdress this issue, especially in light of how much time it's taking me to get Cartogratour into something resembling my original vision for the game. So in this episode of the adventure mechanic side quest, I'll be doing a little bit of naval gazing and comparing what I thought I needed for motivation when I started and what I think I need now and see how they compared to each other.

In my second blog post, I focused on three things that I thought were hindering me from completing a game: lacking the rush of game jams, the quick burst of game jams versus the slow burn of finishing a game, and the issues of being a solo developer. When I first wrote that blog post (link to it in the show notes), I had done about 6 months worth of game jam games. This equated to about six or seven different games all in various states of having a complete core gameplay loop. That means they're all incredibly rough and barely have anything beyond the core gameplay loop implemented. But, as these are technically games, I felt that I was doing very well in terms of being a developer. At the time, I was working on a number of small prototypes, none of which were worthy I guess, to develop further. Despite that, I felt that I could finish a game and publish it in a relatively short period of time. I mean I got six games out in 6 months, why couldn't I polish one of my prototypes to completion? Now that I'm almost a year into developing cartographer and don't have anything beyond that prototype to show for it, I see that getting a prototype and finishing the game are two very very different things.

To be honest, the rush of game jams is hugely addictive and over estimates your ability to actually build a game. All of the patchwork and papering over that has to happen in a jam are these sort of decisions that are much harder to make when working on your own game. All the shortcuts you make to get the game done in the time frame just don't quite work when you're developing the game yourself. You end up having to go back and rework those quote unquote patches over and over again to make your vision a reality. You have to focus a lot more on polishing than you normally would in a game jam. And I think I was off on the wrong foot when I started thinking I was a game developer because I made six (or I think 16 at this point?) games for game jams. In short, I was able to beat the spread metaphorically speaking and actually set myself up for failure.

I kind of foretold that with my second point. I instinctively knew that it wasn't going to be as simple as a game jam to get a game out, but I still underestimated the amount of effort that goes into actually completing a game. And, maybe it's just being locked away for so long talking, but I underestimated how much work would go in to fighting myself. Doing things that I don't want to do, or haven't come up with a good answer for, yet, is especially difficult for me. Sometimes I end up just staring at my code, not knowing what to work on, or worse yet actively avoiding the things that need to get done to get to that next milestone. I find myself doing this more and more as I get into the more complicated details for Cartogratour. I'll be honest, there have been more than a few 0% weeks, which is the concept of not getting anything done on your game over a given period of time. As this is quickly becoming too introspective, I'll leave that for a bit later.

Difficulties I've run into with cartographer actually ties in nicely with the last bullet point of this post. In the third bullet point I talked about being a solo dev, and relying on yourself to get things done. To that end, I am still crappy at this. Accountability is a thing, and I am terrible about it. If I haven't mentioned it before, I run a game developers forum every weekend. For those interested in what we do, we go over some game theory, what we've done on our games over the last week or whatever amount of time it's been since the last forum, and then go over some lenses to look through for our game. In this context, it's a game design lens. If you're interested, there's a link to the book and the lenses themselves in the show notes as well. This is been my primary form of accountability over the last six years. And although it's been a hell of a lot of fun, it hasn't actually helped me actually get a game out the door. I find myself putting more effort into the forum in some weeks than I do into my games themselves. This is becoming increasingly problematic, especially considering I know how limited my weekly time is, and what I need to do to get cartographer into a more playable state. I can see why some people want to quit their day job to focus on their game, gambling on the facts of that it's going to be successful enough to support them moving forward. Unfortunately, I don't have the faith in my own game design skills, nor do I have the desire to risk my livelihood on a bet like that.

So, where does this leave me? Well, since we've been having a bit of a hiatus for the main line adventure mechanics, it's given me an opportunity to use these side quests as a form of accountability as well. That's why I'm taking a look at my seemingly perennial weak point of self-motivation for my own games. If the last year and a half has proven anything, it's been that left to my own devices (and without having external social commitments), I can't actually get a lot done. I think the key is, though, that I have to be able to say no I need to focus on x today. Despite being an introvert, I do thoroughly enjoy spending time with people face to face. It is obvious to me, though, that I need to budget at least one day a week or something to focused game development time. Talking about game design and researching it is great and all, but if you're ostensibly a game developer, you still need to sit down and actually design and develop games. And I think I haven't given myself enough time over the last few months to do so. We'll see if a dedicated amount of time will help in terms of actually getting a game done.

So, have I changed much as a developer?  Not really.  I still thoroughly enjoy the rush of game jams, especially when working in a team to get something done.  I still need to internalize that making games for a jam does not equate to making a commercial game for release.  If anything, doing game jams can put you into bad habits where you think that you're actually further along than you really are.  I really need to get the last few features into Cartogratour and start the polishing phase so I can call out for some more in-depth playtesting.  I feel that there is a good nugget in what I have already, and if anything, having people look at it and give feedback will motivate me to get more done.  Accountability is going to be a continuing issue, especially since this is my hobby and I don't really have the push to get it out that I would have if it was my job.  I'm partially okay with that, however, since I just want to release the game for people to enjoy, and don't really expect to make much, if anything, off of it.  One of the curses of making your hobby your job is that it no longer is fun.  At least, so I hear.  I don't really want to ruin game design and development for myself by pushing so hard that I burn myself out.  That's not to say I don't want to have my work appreciated, it's more so that I don't want to jade myself.

Where is Cartogratour at right now? I'm actually in the middle of putting NPCs into the game. This is a non-trivial task, especially given the rework that I did a couple months ago, but I still need to get it done since it is one of the core tenants of Cartogratour. I went on a bit of a side tangent and attempted to put a day night cycle into the game, but I ran into a limitation of pygame where changing too many surfaces at once will severely degrade performance. I may end up having to cut the day night cycle from the game at this point. Either that or radically change what's the day night cycle looks like in the game itself. This is been one of the issues that I haven't really wanted to address, obviously. It sucks having to run into those hard limitations and trying to find a workaround. We'll see if I can come up with an adequate work around in the next couple of releases, though.

That's about all that I have for the adventure mechanic side quest this time. As always, if you have any suggestions, comments, or questions reach out to me on Twitter. My handle is @jcsirron. This has been the adventure mechanic side quest and I'll talk to you next time.

Some Issues Getting Feedback

I am doing a podcast with my friends about games (check out The Adventure Mechanics here) and I decided that I need to try for accountability on actually releasing a game this year. To that end, I'm going to go through the development process to release a game. Here is the transcript from the second episode on some issues getting feedback for your games:

Welcome back to The Adventure Mechanics Side Quest and, once again, it's just me, Chandler.  I am using this audio format to push myself to complete one of my prototype games and have it ready for a larger release.  Last time, I said I would have the prototype ready for you to look at.  I made it through most of my pre-production goals, but ran into a few snags along the way.  I did make it through the art mockup for both representing the map and player avatar in the overall space. Once I was done with that, I started looking for my previous code base to springboard off of.  To my horror, I couldn't find the original source code for The Mapper.  I only had my compiled version of my entry.  That meant I had to start from scratch on it.  I was able to recreate the basic movement of the player quickly.  I even added a little bit of polish where the player will shift in the center of the screen a bit as they move around.  I even reached feature parity with the jam entry version and added objects that spawn in the tile that the player can collide with.

The map portion of the prototype pushed me into a desert of redesign, however.  I realized that in my original jam design, I limited the size of the play area.  Meaning, the player started on an edge and eventually hit the other side of the map.  This ended up being in direct conflict with the game design I wrote out for pre-production.  So, I had to stop looking at the old compiled version of my game jam game and start working towards my planned design.  I wrote the map to be able to add to the existing map for an arbitrary amount of time.  Moreover, the map that I wrote pulls double duty and handles both the meat space and the map space with no code duplication.  I'm particularly proud of that fact.  This ended up taking much longer than expected, though.  I did end up with a much more flexible design in the end, but it meant that the month I budgeted for this prototype went right out the window.  This forced me to decide whether I was comfortable with sacrificing my original timeline I had envisioned and keep moving forward with what I have currently.  Since I'm terrible at decision making of this caliber until it's far too late, I ended up just adding features to my prototype.

The other thing that this meant was that I didn't get any of the art assets completed for this prototype.  All of it is blocks and text.  Sure, I have the mocks that I made, but they are cobbled together from assets pulled from Open Game Art dot org or existing copyrighted games.  That won't do if I plan on showing this to anyone.  Moreover, I don't want to introduce the possibility of missing those assets later and having them sneak into my final product.  That sort of potential is something that will keep me up at night with cold sweats if I put copyrighted assets in.  I don't want to even flirt with the potential of getting a Cease and Desist on something I spent so much time on.  But enough about my progress, let's get into a topic I want to talk about today: Feedback, specifically issues when getting it.

I have tried getting feedback for my games many times.  Over all the games I've shown and tested, I've noticed a few things that reduce the feedback quality:  First, and most common, is the audience I'm getting feedback from is not the audience that would get excited about my game. The second issue I run into is vague feedback.  And lastly, I end up getting irrelevant feedback to my game in particular.  Let's go over these points:

The easiest people to get feedback from are your friends and family.  I mean, they're right there, sometimes literally.  They tend to give the WORST feedback when it comes to your game, though.  My partner really isn't into top down mapping games, so she's not really invested in what I'm showing.  My family don't really play video games and they only play a few select board games, so there's they really don't have a point of reference to compare what I'm coming up with.  And as much as I trust the opinions of my fellow Mechanics Devon and Tom, they're not going to give me as hard of an opinion on my work as I really need.  For better quality feedback, I'm going to have to search outside my social circle.  Other developers make decent guinea pigs, since they're familiar with the early jank that prototypes entail.  Other good playtesters are groups that enjoy playing games in an early state, or otherwise rougher than normal.  Before the pandemic hit, I was going to local Protospiel events.  For those who don't know what those are, it's a gathering of playtesters and designers who spend a weekend playing games in various states of readiness.  In my case, these were for board games.  Another good option is local meetups for game developers, such as an IGDA chapter.  I'll throw a link ot them in the show notes.

As for vague feedback, I run into this VERY often.  In many cases, the person giving feedback isn't sure what to respond to, so they say, "yeah, it looks good," with little or no additional feedback.  Other times, they see something, but don't want to hurt your feelings/insult your work, so they end up sugar coating their feedback. Both of these are supremely unhelpful.  If you're going to grow as a developer, you're going to have to get comfortable with prying out the details from these people.  Sometimes, when you're asking for feedback, it's worded too broadly.  Questions, such as, "how do you like it?" and, "what do you think?" aren't enough for your playtesters to latch onto.  You need to ask some probing questions, especially in the areas that you're looking to have them really look at.  In the instance of the prototype I have, questions that would be more helpful for me would be about the controls.  Since I have not implemented any of the artwork or audio, questions about the feel of the game are not going to get me useful responses.  The guiding questions that you want to be asking will put a highlight on certain mechanics but not bias the answers.  So, in looking for feedback on controls, I wouldn't want to ask, "were the map controls awesome?"  In that question, I'm trying to bias the responses towards a positive comment.  That's not going to help me get honest feedback.  I'm not going to go over biasing questions, but be aware of it as you craft questions.

The last issue I commonly run into is people giving "advice" on how to improve my game, or worse yet, advice on how to change your design to match an idea they've had.  Don't get me wrong, suggestions on how to improve the overall feel or change a mechanic for the better should absolutely be taken.  The type of advice I'm talking about here is something like, "Hey, I like your game about mapping, but it would be a lot cooler if it was a game about fighting!"  Not only is this not going to help my design, it's actively pulling my design away from the core that I've so painstakingly put together.  The most input feedback that this gives is that the person giving it wasn't really interested in the design.  This may be useful, especially if that person represents a group you want to appeal to, but more often, it's just not going to be worthwhile to implement their ideas.

This only scratches the surface on the topic of feedback.  There is a whole field of study on it and I'm not an expert in it by any means.  This is just my experience when I've tried getting it for my games.  If you've ran into issues as well and want to either talk about it or have me talk about it in a future podcast, reach out and leave a comment.  I'd love to hear your experiences while playtesting.

In the interest of getting feedback as early as possible, I'll be releasing the small mock-up of what I have so far for the map user interface (UI).  There won't be anything in terms of gameplay, but I still want input.  Hopefully I'm making it obvious that it's almost never too early to get feedback on your design.  Yes, the game is your baby, but unless you are planning to never release it, you're going to have to be comfortable with the idea of people looking at it and, occasionally, trashing your idea.  Although it may be hard to hear, even those who trash your game are giving you a nugget of truth, even if it's something as simple as, "I'm not your target demographic."  The more you have people look at your design, the better the game you're designing will become, even if doesn't feel like it at the time.  Who knows, maybe they'll even give you that one tidbit that solves an issue you've dealt with for a while.

Oh, and in that same vein of fast feedback, if you are listening to this podcast around the time of release, OMGJam8 is coming up November 6th through the 9th of 2020.  I plan on entering it to scratch my itch for some rapid development.  I'm not sure what engine/framework I'm going to be going with, but I'm really looking forward to participating in another jam.  I missed out on Ludum Dare 47 and want to push myself with time crunch another time.  If you haven't given a game jam a try, join me in the OMGJam.  It's a fun way to practice, learn, or just execute on an idea that's been rolling around your head.

Anyway, that's all that I have for this episode of the side quest.  As always, you can reach me on twitter as @jcsirron.  I'll talk at you next time.

On Random versus Luck

As I hosted the Game Developers Forum at the TinkerMill last week, we began discussing the concept of luck.  It started with a video by PBS on the topic.  In it, the host Jamin Warren equated luck and player skill in the game Dark Souls.  I initially found this to be rather incompatible when it comes to player interaction; After all, when I'm rocking a game and showing it how I've mastered the mechanics it laid before me, I don't really consider that to be luck. From a developer perspective, Jamin argued that the skill of the player could be considered a form of luck.  One player can struggle with one section while another will simply breeze through it.  I'm not entirely convinced of this argument, however.

First I must try to tease out the difference between random and luck.  I don't feel that these two concepts are interchangeable.  When someone is "lucky," they are assigning either goodness or badness to what just happened. A gambler will say, "It was a lucky streak," when they win several rounds on the roulette table, despite it being an almost completely random game.  Where the ball lands on the wheel is almost completely beyond the control of the player; It is no more likely to land on one number over another (wheel rigging notwithstanding), yet the player will assign a quality to it.  "It was a hot streak," "I had a bad run," or "It was a lucky drop," are all things you could commonly hear around a roulette table.  In this context, luck is an emotional quality the gambler assigns to the random outcome, not the random outcome itself.  I feel that this nuance was somewhat lost in the PBS presentation.

With that framework in mind,  I want to re-examine the assertion that Jamin Warren postulates; That a player's skill can be considered luck in the mind of the designer.  If we agree to this viewpoint, "lucky" streaks that the player has are nothing more than anomalies when compared to the aggregate of player performance.  This doesn't really seem like an emotional response, especially with game design in mind.  These streaks are more likely the players that have mastered the game, rather than the ones that merely gotten a good run. Although interesting, this should not have an emotional component conflating the outliers.

Another view of the player skill he mentions is "luck execution."  This is the idea that no matter how good a player is, they will fail a certain amount of the time.  The reasoning he states for this is the "human factor," or the fact that we, as human beings, are not perfect.  No matter how well we know a game, we will have a lapse of judgement or something that prevents a perfect game.  Although interesting, I'm not sure that this is quite the same as luck.  This lack of a perfect game is what makes pursuits of high scores and speed runs worthwhile.  It's not exactly luck that gets the high score in games like Mario, where any given board is not likely to have a random element.  Rather, it's the focus of the player and the mastery they have over the mechanics.  A lapse in mastery is not necessarily the end for a great run.  This, too, runs into the outliers, where perfection is the goal, unlike the bulk of the player-base.

Although Game/Show has a good description of luck in games, it plays a little too fast and loose with terms to be a great resource on the topic for my tastes.  I understand the ideas this particular episode was trying to convey, but I think it misses by a bit when it tries to equate luck, random, and player mastery into one blanket term.

Analyzing my first few attempts at Ludum Dare game challenges (Part One)

I have been looking back at my previous entries into the Ludum Dare lately.  It feels like every time I work on one of these games, I come away feeling great about it.  I rarely look at them a second time, however.  As I have some downtime before the next Ludum Dare, now would be as good a time as any to compare my post-mortems to what the ratings actually said of them.

First up, we have my first ever entry, Lobo.

This being my first ever game created with a team, I felt very good about the outcome.  The strongest portion of our game happened to be the audio.  We found the audio online, using free music (as in the music that can be used for general non-commercial use) and used a few sound clips we made.  I feel that made audio point somewhat of a caveat, since we didn't create all of the assets.  The lowest score we got was in fun.  As the game only had walking brains and no win condition, I'd say that this was a fair critique to have. There wasn't much in terms of gameplay here.  The graphics were a second strong point we had.  I'll do a full post-mortem on this game later.  Onto the next one, The Orion Trial!

Not to be confused with Schell Games The Orion Trail, our Orion Trial ended up being a standout game in terms of rankings, despite having no audio.  We ended up ranking in the top twenty for humor by filling the game with humorous sci-fi references.  It ended up being just a game of random number generation, but no one seemed to care about that weakness, at least judging by the fun rating and the comments.  The weakest portion of the game was the innovation, since it was a clone of the meta-game in Oregon Trail. I personally spent way too much time working on a parallax field, which I felt added polish to the game, but didn't help the fun factor of the game.  I know that I didn't really care about the looks of the original Oregon Trail.  The main part of the game that I liked was the mini-games: Packing up as many bullets, ignoring almost all other supplies, for the hunting mini-game was what I did as a child.  Having no mini-games in the Orion Trial made me feel like the game was somewhat unfinished.  One commenter left one hilarious post, however:

 fisholith says ...
"Cool concept, I love the encounters. :)
On one mission I recruited no fewer than 4 LRRRs. They all died.
On my next mission, my ship had been built on top of an ancient space burial ground. One which also seemed to travel with the ship, because wow, was that ship ever haunted. Actually ... now that I think of it ... there were more ghosts on that ship then crew. Oh my various space gods! *WE* WERE THE GHOSTS!

But also we died later."

Loot Runners was a seeming back-slide in terms of finding that magical mix of game.  I only worked with one other person on this game, but I still am only somewhat happy with the results.  This was our first attempt to create a game involving multiplayer.  The comments on this game were appropriately critical of the execution.  There was not much in terms of gameplay, nor was there much in terms of eye-candy.  What seemed to frustrate the players the most was the lack of feedback.  I think this could have been solved if the player image shook or the monster shook when they attacked you.  What we did do right was sticking on point with the theme.  The entire game was on a single screen.  One bright spot in the game was using a giant killer rabbit for an enemy.  Once again, it was not an especially innovative game.  As a first stab at a local multiplayer game, however, I am pleased with the results.

I will continue the analysis and data visualization of the next three games in the next post.

Royal Flesh Post Mortem

Well, another Ludum Dare down, and another game out.  It's been a week since we finished and published what I thought was a functioning game.  Before we delve into what went right, wrong and ugly, though, take a few minutes to try it out here.  I'll wait.  Tried it?  Good!  Leave a comment about it and I'll be sure to read it.

Now time to do the post-mortem!

This game went surprisingly smoothly, save for a few particularly bone-headed moments and a LOT of frustration getting cxfreeze to work properly (seriously, how can you forget to include something that is IN the include call?)  We started out with a long idea session that seemed to center around an idea called "Grammar Nazi."  Thankfully, that idea didn't hold enough interest to develop and we settled on the trope of abducting royalty as a dragon.  I even got ambitious and got the framework for the game ready the first evening.  I went home to bed happy, thinking that I had gotten so much done already.

The next day I got into a HUGE memory leak due to my framework not properly closing out when switching between screens.  I spent an hour working on getting that migrated over to objects instead and then implemented the item system.  At this point, we had an artist that we were supposed to be sharing with another group (thanks again, Tamara!) and things felt good.  We even had a few teenagers helping out with the audio portions.  I brought in my home-made sword and so did Brian, so we had props for making convincing sound effects for the game as well.  As the day dragged on into the evening, things started going sideways.

Our awesome artist couldn't work with us anymore, since she had prior plans.  That left us with about 3/4 of the assets we needed and no one to do the rest.  I was looking at doing artwork for some time, so I stepped up and started jamming on the art, leaving the code work to Brian.  The guys working on audio were not really into it and started messing around with two shiny swords outside.  They claimed they were making sound assets, and they did, but their methodology could have used some... work. After about an hour (maybe more, maybe less. I was lost in artwork), they came back in with dinged swords, cracked chain maille and apologies.  Apparently, they used the equipment improperly and caused quite a bit of damage.  I was so engrossed in the artwork, I forgot the first rule of teenagers: Never give them dangerous things without supervision.  I went home that night with a rather sour taste in my mouth.

The next morning, I got in and attempted to start working on art again.  I was immediately foiled by a broken tablet pen.  Just as I was getting comfortable with it, too.  I had to go grab a mouse to work with and got back to art.  Thankfully, the rest of the development process went smoothly.

When we went to package the game up, we had troubles with it packing up nicely for mac.  We spent an hour working on it, but to no avail.  I was getting tired, so I packaged up a Windows build, tested it and went to bed.  Apparently I should have tested it on another computer without python installed, since I looked at the progress of voting and found a long list of "Broken game!" comments on the site. I just figured out that cx_freeze was not including pygame._view in the build, rendering it useless.  D'oh!  At least now the game is playable.

Ok, time for the Good, the Bad, the Ugly:

The Good

• We released a game!
• I got to do some artwork
• Scope Creep wasn't really an issue
• Execution was very close to the original Idea

The Bad

• Artist had to duck out
• Bad build on layman PCs
• Broken equipment (tablet pen, swords)
• Animation had to get cut back for the Nobility

The Ugly

•  Broken chain maille
• A week's worth of "Broken Game!" comments on the Ludum Dare website

Failure.... Yet again.

Well, Game Boy Jam didn't go well for me. Real life got in the way.  Again.  I sat down throughout the week to jam, but either my motivation vanished, I got stuck and lost steam on the project or friends and family needed my attention.  It is endlessly frustrating to have to write this post about bowing out of the jam.

I started the jam with an idea of a princess, one who tired of waiting for her prince.  Over the first few hours, I imagined that it would be a stealth based game, where you, the princess, are helpless to stop the invasion of your castle.  Your only hope is to escape the pillaging and survive.  I quickly realized that this was going to be difficult to implement this initial idea.  I spent a few hours getting a semblance of a game running, but I had to shelve it until another day, or so I thought.

The next day, I was able to sit down and work on the artwork of the game, but I was frustrated by my incredibly rusty art skillset.  I have been working with artists on every jam since I started doing them two years.  During that time, I have not drawn anything more than a doodle, let alone flesh out an entire cast of characters (I was going to implement five of them). I fell back on my schooling and started doing warm-ups.  They went well, but they didn't exactly help me get a whole character committed to a sprite sheet. After pounding my head on my tablet for a couple of hours, I called it a night and went to bed.

With the beginning of the week came work and all of the distractions that entails.  I was able to get a few hours of work down on the artwork, but I fell into the rusty knives of dulled skills again.  The rest of the work week was too busy for me to sneak some time in for the jam.  Needless to say, I was looking forward to the weekend, where I could jam without the messy distractions of working and preparing for school.

As the weekend began Friday, I had two ultimately fatal complications pop up.  The first was a previous commitment of working on my girlfriend's family farm Saturday.  I was only expecting a half-day of work, since it sounded like we'd only be doing a few things.  I was wrong. Very wrong.  I barely had time to snag a shower before having to go to the weekly Game Developers Forum.  I didn't get time to work on the jam that day.

The second complication was having an old friend surprising me with a visit.  I mentioned that I was jamming at the time and he seemed willing enough to help.  As I sat down to work Sunday morning, though, he fired up his latest gaming obsession: Rocket League.  I only got about a half hour of work done before finally succumbing to the allure of gaming.  It ended up nuking the whole day.  Not that I regret anything.  I got to see an old friend and see a new game that I had only heard of before.

Ok, enough of the blow-by-blow account, let's do the Good, the Bad, and the Ugly of this post-mortem.

The Good

• I got to verify my latest additions to my code-base
• I implemented a better chase algorithm for future use.

The Bad

• Previous commitments killed any hopes of getting a game done.
• I surrounded myself with those who impeded my progress.

The Ugly

•  A half-baked, only partially completed game.

Although I got practice like I wanted this jam, I would have been much better off cloistering myself for a shorter amount of time and getting more done.  Life had a way of screwing over my intentions of joining this Game Boy Jam #4.  Lesson learned.

Chomping at the Bit

So, I've gotten the game jam fever and couldn't wait until the next Ludum Dare.  I know; the next Dare is only two weeks away.  The thing is, though, that I've been really inspired by some of the theme ideas.  That's not to say that there are bad ideas, there are a ton of them.  The gems that I do find going through the slaughter are worth the sifting, though. I have a horrible bias towards themes that can lend themselves to either fantasy or sci-fi wrappers. As I worked my way through the slaughter, I thought to myself, "man! I really want to start jamming on a game!"  And that's how I ended up starting the GBJAM.

The Game Boy Jam is an interesting one.  Instead of the focus of updates being on the website itself, it instead leverages Twitter for the vast majority of it's updates.  I'm not quite sure that I'm a fan of this, since that means yet another social media platform is scraping my information.  I don't know how, but Twitter scraped my G-Mail for people to follow.  Grrr.  That's a rant for another day, however.  I'm here to talk about the jam, not the social media aspect.

From what I can tell, the jam isn't as popular as the Ludum Dare (duh!). I do see a lot more cross pollination, though.  A few users have been religious about updating and now I've seen several different versions of what a 3D game would look like using a Game Boy screen. Weird.

Another departure from the norm is the time allotted.  Ten days.  Yeah, that's right, ten days.  Wow, that's a lot of time.  It almost hits the point where I'm able to put off stuff until the last day.  Not that I would do that (sarcasm).  This is a departure, since the jam now starts to bridge the divide between a quick burst and a slow burn.  I'm not sure that it's good for me, personally, but I am giving it the good old college try.  We will see how it turns out.

The last part of this puzzle is my team: Me.  Yep, that's it.  It's just me this time around.  I've had a blast working with others every game jam, but I feel like I need to be able to jam alone.  So, that's exactly what I'm going to do this time around.  And yes, I don't have much to show for it except these puddles chasing a red one around.

Now if I can get used to the whole Twitter feed for updates....

- Chandler

Ludum Dare 32 Post-Mortem

In preparation of another Ludum Dare, I am reposting my post-mortem from the last Ludum Dare.  To those who are joining for the jam or compo, good luck!

--------------------------------------------------------------------------------

Well, It's been a week since we submitted our game, Break A Leg, and it's given us time to think about what we have done.  It was a blast to make and I personally am proud of what we had made.  That being said, I feel like a proper post-mortem is in order.  Let's do this!


The Good:
Playtest the game mechanics the first night.  Most of the Ludum Dares I get lost in the details of making the game that I don't stop to think of whether my game will actually be *fun* or not.  So, playtesting the game mechanics night one made me much more confident about the direction of the game.
I had backup for programming! This one was personally huge for me, since it gave me more time to think about the structure of the code and, consequently, make better code.  A larger group also let us have some backup on each area of work.  The extra help on art and code made a much better project.
The Bad:
Time.  I know this is a common item on the bad list, but having some extra time would have been immense. Everyone had work on Monday, so the last day of the jam really wasn't an option.  We worked as late as possible and got a lot done in the final few hours, but we didn't have time to get the audio that we recorded into the game.
Split work areas.  Since we had a larger group than expected join us at the TinkerMill, we had to move into the main area for the Dare.  We had the people doing art and sound working in one area and the programming group working in another.  That led to a few issues with user interfaces and misunderstandings about what the vision of the game would be.  Although we mitigated confusion by planning thoroughly the first night, some details fell through the cracks.
The Ugly:
Having to move into the central area.  The main area was quite a bit louder than the conference room we were initially going to use, so it affected how focused we were on the game.  It wasn't a huge deal, it just made it take longer to get done.
Not participating in the warmup weekend.  I was a bit rusty on the coding side, so it took me longer to get moving on the code than it should have been.
Next Time:
Reserve the classroom.  I think that this would solve the split work area issues, along with the noisier work area.  This is easy enough to solve, though.
Practice!  Working on games is not a short term endeavor, so not practicing the art really takes it's toll between the Dares.
As always, it was a blast to make this game and we look forward to jamming again next time.

Adventures in Quad-Trees!

This past week I have been looking into implementing a quad-tree data structure in my game engine.  Although the amount of stuff on-screen in most of my games may not really benefit from it yet, I figured now would be the time to implement it before I face massive slowdown from too much shiny (á la fancy particle effects that bounce off of players, walls, etc.).

For those who are in the dark about what a quad-tree is, it's a specific data structure that can significantly streamline collision detection.  The basic concept is that the screen is split into zones as the number of objects on-screen increases. Once the number of objects on-screen reaches a threshold, the quad-tree splits the screen into exactly four quadrants.  Each quadrant can only contain so many collidable objects. If there are too many objects in any one of these quadrants, that quadrant can then be split into four more quadrants and so on, until each portion of the quad-tree is either at or below capacity.  Once you have the objects placed in different quad-trees, you can then check collision between only those inside the specific quad-tree rectangle and not check against one across the screen.  This can potentially save significantly on collision checks

Now, I know I asked myself, "Why would I want to do this?  Isn't it cheaper to just do collision tests on all of these objects at once?"  After all, all of my games up until this point have had only a handful of objects on the screen at once, and only a few objects cared if they collided with anything.  The first game I made, Log Jam! only cared if the player collided with any log, not if any logs collided with each other.  This led to some really weird problems, where the logs would "ride over" each other.  Although this was purely an aesthetic issue, it has always kind of bothered me.  Implementing collision logic between the logs would add variety in movement to each one, and make the game more dynamic overall at the cost of a LOT more collision checks.  This is where I could have implemented a quad-tree system to minimize the number of checks I would have to do.

An example of a collision issue in Log Jam!

Another example of wonky overlap with the logs

Working with Log Jam! as an example, let's go through the number of checks that we would need to do if we are later into the game, where there are a bunch of logs on-screen at once, such as in this screenshot:

A late game screenshot of Log Jam!

 In this shot, there are ten collidable logs on the screen (the waves are just for polish and aren't affected by the logs).  In this example alone we have 10 log collision checks to do, coming out to 45 checks minimum to make each time through the game loop.  If I was sloppy in coding (as I sometimes am), the number of checks would be closer to 90, assuming that I forgot to cull redundant checks.  Keep in mind that each check is a simple rectangle collision check, relying only on the bounding box of the log.  Even in this example, that is a lot of checks!  Let's break this into a more manageable size:

The same screen broken into a quad-tree

Now in this example, our parent quad (the entire screen) only has two objects in it, the log straddling one and two and the player's raft. quad one has two objects in it, two has one, three has two and four has three.  Let's go through the math: the objects in the parent node have to check against all of the sub-nodes and each other, netting 17 checks. The logs have to be placed into one of the quads, netting in another 24 checks.  Once all of those are into quads we can check each: quad one has 1 check, quad two has no check, quad three has only 1 check and quad four has 3 checks.  This leads to a total of 46 checks.  Hmmm... Not much better, is it?

If we limit our checks of the parent node to only those sub-quads that the object hits we can cut the number of checks.  For example, the player's raft will only hit quads one and three, that check alone netting us 4. we then compare the raft against quads one and three, netting another 4 checks. Doing the same with the log, we net 7 checks, cutting our total collision checks to 15.  When we put this into the our previous calculations, we end up with 44.  Not great, but a modest improvement.  The more objects that appear on-screen, the better the results we will get.

In my example, the quad-tree algorithm adds a lot of overhead to collision checking, so in this case, it may worthwhile for Log Jam! If there was a lot of collision checking that I had to do, such as where I was dealing with something where the logs rotated and the collision checks weren't just dealing with rectangle checks, but whether a rotated object indeed hit another, the quad-tree would make more sense. Having it in the toolkit for speeding up the game loop doesn't hurt, however.

Well, that's my broad-stroke analysis of quad-trees.  I'm sure that I'm missing something in this, but I just wanted to write my way through the problem before diving deep into the code.  If you have any questions/feedback, leave a comment.  Thanks for reading!

- Chandler