The Case for Game Jams

 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 third episode on the game jams and what to expect when entering into one:

The case for Game Jams:

Welcome back to my Side Quest for the The Adventure Mechanics.  I'm Chandler and, once again, it's just me for this episode.  Between episodes, I participated in a Game Jam called OMGJam8, link in the show notes.  If you've listened to the last two episodes of the side quest, you'll know that I talk about game jams.  I talk about them a lot.  And I haven't really explained the anatomy of a game jam. So, let me divert from progress on my game, which is in the middle of making and putting art assets into it, to talk about the process of participating in a game jam.  Trust me, this is still relevant to finishing my game for wider release.

WHAT IS A GAME JAM:

For those who haven't heard me rant about game jams before, a game jam is a a time-limited game design challenge where a theme or restriction is given at the beginning of the jam.  Once the timer starts, the developers or teams have the time given to come up with a design and execute on it.  It's the entire design and execution process condensed down into a small chunk of time.  It's a great way to determine where you're weak in the process and improve on it.

Now that you have a general idea of what a game jam is, let's talk about preparing for one as a participant.

GETTING READY FOR A GAME JAM:

First and foremost, you're going to have to set time aside for the jam.  Like, all that you can muster.  Make sure that you're not committing to any social engagements during the jam.  Let everyone who could interrupt you know that you're going to be unavailable during that time.  It may be obvious, but interruptions during the jam will pull you out of the flow and need to be mitigated before the jam starts.  It's hard for me to get back into the state of flow once I'm jarred out of it, so this early mitigation strategy really does pay dividends when I start.  Next, make sure that you have all provisions needed for the jam before starting.  Need caffeine?  Grab enough for a crunch.  Need snacks?  Grab days' worth of your favorite snacks.  Need to force yourself to sleep (and get up early)?  Set alarms to remind yourself when to sleep and when to wake up.  And don't forget to take care of meals while jamming.  All of these preparations will save you from spending time during the jam figuring them out.  That mental overhead does not need to be there and taking care of it will keep you working longer on what you want to.

When you're done with physical and social preparations, then comes time for getting your tools ready.  This may sound like a given, but I've seen many teams spend an inordinate amount of time learning their tools and getting them working during the jam.  This is not only counter-productive, but also a sign you're not ready for a jam.  If you want to practice with a new framework or engine before the jam, then do a dry run beforehand.  Go through a couple of tutorials so you know the basics and package/build your results.  This will save you time during the jam trying to figure out the packaging process works for the engine.  You don't want to go through the entire jam only to get stuck at the end trying to figure out how package it up for release.  It's hard to diagnose issues when you're tired and burnt out from a weekend of jamming.  Trust me.  I've ran into this exact issue multiple times and hate myself every time.  Don't do this to yourself.  Prepare!

STARTING THE JAM:

Once you have all of your affairs in order and you are comfortable with your tools, it's time for the start of the jam!  If it's a theme release, you will want to brainstorm some ideas on what you, and potentially your team, want to make.  Brainstorming will help you organize your ideas and how feasible they are to get done during the jam.  It may feel like it's a waste of time, but like the preparations made before the jam, it will pay off later.  Don't go with your first idea.  It may not be the best one for the jam.  Work out several ideas and keep the scope as small as possible on each idea.  As you work through them, you'll likely lean towards one idea that you particularly like.  Spend some more time on it and flesh it out some more.  If it fits the theme and you feel confident that you can complete it, work through what needs to done to get the game to your vision.  Write out all the details in a way you can track.  Some ways that I've done this is writing everything on a whiteboard, putting everything onto sticky notes or sharing a Trello board.  However you organize it, make sure that you're updating it as you go along.  Planning without followup is not very useful.  It's also nice to see the progress you've completed when you move the sticky note or erase the task from the board.  That little action may be the difference between getting overwhelmed and actually completing the game jam.  Every thing you can do to keep motivation high is something worth trying.

WORKING THROUGH THE PAIN:

One thing I've noticed that isn't really mentioned whenever someone talks about participating in a jam is the inevitable exhaustion and blocks that come up.  Exhaustion is going to happen.  That's normal.  I have hit this every time I have participated in a game jam.  Every one.  Taking a break, a nap or a walk aren't going to bite into your dev time more than you trying to "gut" through the exhaustion is going to.  Do what you need to do to get back to a good mental state.  If you're working exhausted, you're not giving the jam your best.  The same really applies to all things, come to think about it.  In that same vein, hitting a design or mental block isn't something to fear, either.  You're going to be working on a whole game all at once.  Getting stuck on one thing doesn't mean that you're no good at being a dev.  It means you may need to switch to something else or spend some time away from the game.  There are going to happen and you'll want to accept it early so you don't spend time fighting it instead of developing.  It's all about getting a complete game.

FINISHING STRONG:

When you have a complete game, congratulations!  It's no easy feat getting a game done on time for a jam.  On the other hand, if you find yourself running out of time and still have that wall full of things to do, it's time to finish what you can and prepare your game for release.  You entered into the game jam to finish something, so having something to show for your efforts should always come first.  There's no shame in having to cut features to get your game over the finish line.  Other devs are having to make the same hard decisions to get a finished product.  If anything, it's a sign that you're willing to make the hard choices to finish a game.

As for the worst case scenario, you don't have enough of a game to release for the jam and need to withdraw.  It sucks, but it's going to happen.  Life came up and you don't have the time to finish.  It's okay, don't beat yourself up.  You still learned a lot during the jam.  That's something to be proud of!  Take the lessons you've learned and carry them forward.  It's only a failure if you don't learn from it.  I always feel like crap when I have to withdraw, but every time I've withdrawn, I just couldn't get to a completed game.  Regardless of the reason why you don't finish, make sure that you go through the proper channels and either withdraw or announce that you won't be able to finish.  Don't ghost everyone, especially if others are depending on you.  Be a good participant of the jam.  It's supposed to be fun, after all.

THE AFTERMATH:

Once you've finished the jam, you're not done.  Most jams have a rating period, like Ludum Dare does.  If the jam you have entered doesn't have a rating period, you will still want to go through the entries and play other entries.  See what other people came up with and give feedback.  Not only is it a good way to get feedback on your entry, it's a just a good thing to do for the jam community.  You all went through the jam and it's time to see what people came up with.  Who knows, maybe you'll see something amazing or see someone else you may want to do future jams with.  This little bit of extra time after the jam is important.  Use it!

One final thing that is useful is to do a blameless post-mortem.  It's time to evaluate what happened during the jam, what can be improved and, most importantly, what you did well.  Not a whole lot of people do this, and it's only to their detriment.  Post-mortems are the critical lens needed to grow as a developer and acknowledge your accomplishments.  Go over the project with a critical eye.  If you really need it, use something like an Agile Retro.  I can't believe I just said that, but it's a good tool.  I think I gagged a bit using work lingo in this podcast.  Ugh.  That being said, a retro formalizes the process of doing a post-mortem and may help get it started for you.  I'll link to an explanation of what an Agile Retro is for those interested.

TAKEAWAYS:

So, I've gone over all of this and for what?  Well, being true to myself, I'm going to use this as an opportunity to talk about my entry for OMGJam8 and do a proper post-mortem on my own work.  The theme for OMGJam8 was Recycle.  I spent the morning of the first day thinking of games I could make for the theme.  I ended up with a tile based puzzle game where the player can switch bodies and "recycle" them for the next level.  I initially wanted to use bodies, a la Carbon Frame, but decided against using meat bags, since that would bring up other issues thematically that I didn't want to tackle in this jam.  The jam hosts, Game Devs Quest, provided an asset pack to work with for the jam.  I found some music and sound effect that worked from the asset pack, but the asset pack didn't have any artwork that really inspired me for what I had in mind.  I wanted to stay in the spirit of recycling, so I went out to OpenGameArt.org and found an asset pack that matched the feeling for what I was envisioning.  I found a workable CGA style asset pack with a variety of robots included.  I spent the first night fleshing out the core mechanics.

I woke up early the next day and started implementing the base of the engine I was making.  I spent a good portion of the day looking at rectangles and got sick of it after dinner.  I spent the rest of the night adding and mapping out the asset pack that I chose.  I think I spent too much time getting the asset pack to map properly, but now I have a robust way to map and scale the images for future games, so that is one small win.  By the end of day two, I was able to go through one level with one of the robots, but I didn't have the features unique to each robot implemented yet.  I knew I wanted three unique robots at a minimum, so I knew that I had to come up with something for each tomorrow.  I went to bed thinking on that one.

On the third day, I started by finally nailing down the capabilities of the robots.  I implemented their behaviors and then started making the instructional levels for showing the powers to the players.  I got the tutorial levels implemented and even added a couple more for posterity, totaling five levels for the jam.  I ran into issues with coming up with puzzles for the design I had, but I am happy with what I came up with.  When I finally added the sound effects, music and menus that evening, I felt good about ending the jam on a high note.  Then I had to package the game for release.  It just wasn't cooperating with me.  My first try ended in abject failure, not packaging at all.  I spent the next two hours trying to get a successful package.  By the end of the night, I finally got it working, but I was not a happy camper with the effort.

I had the Monday after the jam off work, so I went through and played all twenty five games entered into the jam that I could play and gave feedback on them.  I got some pretty good feedback from some people and went to bed happy.  On Tuesday evening, a streamer named Darzington mentioned that they would be playing my game with a number of others on Wednesday.  Needless to say, I was surprised that any streamer would be interested in playing games from such a small jam.  I watched her stream while I was working and got admittedly sidetracked, since those were the same games that I played a couple of days before.  There were a number of participants in the chat, so it was really fun spending time with them as Darzington played various entries and gave feedback on each.  There were a number of suggestions that she gave on my game that were very good (and I noted in the code for potential revisiting...).

Overall, I had a really positive experience with this game jam.  I may not have gotten as many levels into my game as I wanted, but I did get more into it than I expected.  Packaging the game up was the main stumbling block I had, and that was mostly thanks to me being tired when I went to package the game.  There are a number of things that I am weak at, especially designing a compelling puzzle, but I felt that I was able to make something interesting despite that handicap.  Having art and sound assets already available for use when the jam starts was a whole new experience for me.  One that I would certainly like to repeat.  In future jams, I may create a few art assets to work with before the jam begins, so I can just pull from them and get working on my idea.  I really liked not having to spend a whole day working on art, only to have to set them aside when I don't have time to implement the mechanic that uses them.  To top it off, participating in a stream that talked about some of the more interesting entries was a novel experience.  For larger jams, like a Ludum Dare, participating in something like that may not be possible, but whenever it is, I will absolutely want to do that.  It was such a wild experience.

Well, that's all that I really want to say about game jams in general and OMGJam8 in particular.  Next time, I'll be giving a beefier update on my game and another topic that relates to it.  If there's anything you'd like me to address next time, reach out to me on Twitter as @jcsirron.  This has been the Adventure Mechanics Side Quest and I'm Chandler.  I'll talk at 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.

The Importance of Pre-Production

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 my first episode on accountability:

Welcome to the Adventure Mechanics Side Quest and it's only going to be me, Chandler, today. This is going to be a mini-series where I look at some of the grittier parts of game design. It's also going to be a form of accountability for me as I take a game from prototype to a more fleshed out game. I have been a hobbyist game developer for a while now, and need a kick in the ass to get a project past the prototype phase and actually publish something. For this mini-series, I'll be taking one of my prototypes I made for a game jam and fleshing it out to a complete game.

So, where do we start? Well, if you haven't done something like this, the first step is planning. It's not the sexiest part of game design, but if you approach it with creativity, you can end up with something great. This first step is going be coming up with a workable idea. How do you come up with a concept? Well you can peruse through old game jam themes for inspiration or looking at an existing game design for your game. The most important part to keep in mind, however, is how much you can realistically make. If you're a solo developer and want to make your Magnum Opus, be prepared for the years of work that will take, despite it, "just being a copy of that sweet MMO/Battle Royale/whatever." The games you're using as a rubric had many developers each with more experience than you. As a side note, if you have made and published a game and are for some reason listening to this, I would love to hear your experiences.

The prototype I'll be using for this is an entry I made for OMGJam6 about mapping the world around you. I called it "The Mapper". It was my first solo entry for any game jam, despite participating in about a dozen game jams before OMGJam. I didn't get nearly far enough to really test out the concept of this game, so I am going back to this and working on getting the prototype more fleshed out. I feel like there's a good game in this idea and I want to spend some more time working on it to see if I can suss it out. For the purposes of this pre-production, I'm giving myself a month to get the prototype out. Here's what I have planned for this game so far:

The pitch:

You are a cartographer that has arrived at a small frontier town in need of your services. Problem is, you haven't mapped the area yet. You need to set out on expeditions to map areas of interest, making sure that you bring enough supplies to survive in the wilderness. With the hard-earned information you gathered, you can then help the town thrive. Be careful to not put yourself out of business, however. A townsperson with a whole map won't need to come back to you for your services again. You have bills to pay, after all.

[The Mapper] is a top down exploration game where the player must manually create a world map and sell portions of it to to make ends meet. The cartographer's office needs to be maintained and the player needs to be fed, creating the tension of the town getting the supplies it needs while not giving too much away where the townspeople no longer need the player.

To further flesh out The Mapper, I'm going to be formalizing the gameplay loops that I am envisioning for it. What's a gameplay loop? A gameplay loop describes what the player will be doing during a typical game session, or series of game sessions. The primary gameplay loop describes the lowest level repetitive task the player will be doing. For Diablo and it's clones, the primary gameplay loop is: kill a monster, pick up loot, sell loot that isn't of value to player. There is more to Diablo, of course, but the primary gameplay loop can be condensed down to that. Any gameplay loop that builds on top of the primary is a secondary (or higher) gameplay loop. In our Diablo example, a secondary gameplay loop is to navigate to a given location, collect an item, and return it to a townsperson. There can be many secondary gameplay loops, but it's important to define all the gameplay loops that you want to implement beforehand.

For my The Mapper prototype, I'm aiming to get the primary and secondary gameplay loops ready. The primary gameplay loop is:

- buying supplies for an expedition

- exploring the world outside town

- noting where things of interest are on a map that the player manually fills out

- returning to town before the expedition supplies run out

A secondary gameplay loop I am planning is going to be something like this:

- player selects townsperson quest from queue

- player selects the tiles (or path) from their map that they are going to sell to the townsperson

- townsperson paths to the goal tile

- if townsperson returns, they go back into the available for gathering resources pool

There will be other gameplay loops that I will want to implement, such as updating the map to reflect improvements, evading predators, and collecting supplies in the wilderness, but this will be enough for the first prototype. I only have a month to finish this, after all.

Once you have your idea, come up with the absolute basics of your design. What are the controls of your game? Are you going to be using existing conventions, such as the traditional FPS health packs or regenerating health? How do you expect the player to interact in your world? Write down the basics of what you want the player to do or feel. This is the most important part of coming up with a design. Once you have that, any feature you consider adding will have to either be in service of your initial design, or the design itself must change to accomodate the added feature. This step ends up forcing you to consider the game holistically, so you check yourself before adding to the game impulsively and getting yourself stuck in a cursed problem where two features you want are fundamentally incompatible.

In The Mapper, I will be breaking up the game into two different parts: The meat-space, where the player controls an avatar through the world, and the map-space, where the player interacts with the map they generate. With the meat-space, I'm planning on it having controls similar to the Legend of Zelda, with one hand controlling the movement of the player and the other interacting with the world. I plan on having support for both a controller and a mouse and keyboard. I'm not envisioning the player needing more than four buttons for interacting with the world. As the player moves around the wilds, they will see interesting features. Features will be of four different types: Landscape, such as forests and rivers, Resources, such as berry-filled glades or fishing spots, Fauna, such as fowl or bears, and Improvements, such as abandoned towns or roads. It is up to the player to notice and note where they find these features on their map. There will also be hazards in the world that the player will have to deal with, but I do not intend to add any real way to permanently deal with flora or fauna hazards. To that end, the player will not have an attack to use on hostile fauna. I envision that the player will be able to carry equipment to placate or distract the fauna, allowing the player to get away. These may be placed into a context menu or basic inventory.

For the map-space, I plan on having the primary interface to be selecting map tiles and either adding or removing features from the tile. Whatever control scheme used for the meat-space will be mirrored in the map-space. That means if the player chose a controller, the map-space interface will accomodate a controller. That means the map-space navigation will have to be flexible enough to accomodate either input method. The controller setup will focus on moving, highlighting and selecting tiles. The keyboard/mouse setup will work similarly, but will not force to have a highlighted tile. While exploring, the player will be able to open up the map at any time and select a tile to add or remove features. The interface will not highlight the tile that the player is currently on, but rather keep the last tile modified highlighted. I do not want the player to use inappropriate clues from the map to verify it's accuracy. When "selling" information to the townspeople, there will be a goal tile and, if there is a specific path the player wants the townsperson to take, a path from town to goal. What the townsperson needs will be shown on screen somewhere during this pathfinding process.

Notice how I haven't mentioned anything about the technology to use when I described the basics of my interface, beyond the input device support. That step will come after you have come up with your design. Pre-existing game engines are great, but some are better at some things over others and your design should guide you towards an engine/language/whatever that is best suited for your idea. If your concept comes with an existing prototype, great! The choice of what to make it in is that much easier. Otherwise, you'll need to consider what you are most comfortable with or are willing to learn versus the capabilities of the engine that you are looking at.

In my case, The Mapper jam entry I created for OMGJam6 was created in PyGame. PyGame is a simple engine that gives me control of input devices and has basic capabilities of drawing to a screen. I chose to continue in PyGame because it was what I was most comfortable with and had enough capabilities for my purposes. I could have used a more feature-rich engine, such as Unity, Godot or Unreal, but I wanted to push myself to really know what was going on in my engine. I didn't want to have easy access to those extra features so I am forced to work them out. That is why I ended up settling on PyGame once again.

One last thing I wanted to talk about for pre-production is creating a timeline. On larger projects, this falls onto project managers who (hopefully) know what the capabilities and limitations of their team are. On a hobby project, such as this one, that falls onto you. Keep realistic goals in mind, breaking it down to accomplishments you can achieve in short time frames, such as a week or two. This is not the time for optimistic projections. This is what you will be using to hold yourself accountable, so build in some padding as you move forward. You don't want to set yourself up for failure and giving leeway for unexpected roadblocks only ensures that you won't fall behind.

In my case, I have broken my progress down to milestones on a week by week basis. I am only doing this on a spare-time basis, so breaking it down further wasn't going to help me measure my progress. I also chose a week length, since I find that I will put off tasks that have longer timelines. So, for the next month, I have a series of milestones that I am pushing myself to achieve. By the time the next episode of this podcast releases, I will have a prototype ready, along with another topic to discuss as I push to get this game to release.

Thank you for listening this rather rambly podcast. As always, if you have any thoughts, questions or feedback, reach out to me @jcsirron on Twitter. This has been the The Adventure Mechanics Side Quest. I'll talk to you next time.

Bye!