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!

 

Role playing and the game designer

I have been playing role playing games since I was a kid, albeit video game rpgs.  Diablo and other action-roleplaying hybrids were my introduction into the game type.  I started playing juicier role playing games later with the Fallout series.  Even as the level of immersion increased with each game I played, I felt as if I was only a spectator in them.  I wasn't free to do as I wished in these ginormous worlds.  The limitations of game engines and developer creativity stifled my desire to play out characters I built.

When I started dating my now wife, I was introduced to the world of tabletop roleplaying.  She is an avid role player and her friends kept pushing me to join.  Being the techie in high school, I always used to make jokes about Dungeons and Dragons, using it as a punching bag.  I didn't want my carefully created self-image to be "sullied" by something as trite as pen-and-paper rpgs.  After all, I was playing much prettier games on my self-built PC.  When I finally caved, I realized how wrong I was about the tabletop and what it means to me as a game designer.

Why is it important?  It puts into stark relief how fragile your carefully thought out story and "immersive" speech tree actually are.  I foolhardily started as a DM, not just a player.  "I've built games, surely building an engaging dungeon crawl isn't that hard!"  Man, was I a fool.  I got my first dungeon crawl mocked up, with a prison that changed layouts and everything.  After an agonizingly long character build session, the party sits down, and...  I break a cardinal rule in DMing.  I dump one of the players into a fight already in progress without letting them know first.  I thought it would build tension and incentivize the party to go to the prison first.  I had no idea that the party would want to actually explore the town.  Tough first step, but not session breaking.

After some rather strained improv, I was able to get the party to the prison and introduce them to their final player character.  They go a bit further into the prison, finding a circular room with an oculus shining light into the center of the room.  At the center of the room was a pedestal and a note.  I figured the party would take a look at the note, maybe a quick glance at the pedestal, and then move on.  That's what I would do in a PC rpg, why wouldn't it work here?  No, no.  They spent at least an hour investigating the room and the pedestal.  Players become obsessed with the oddest things.

After all was said and done, the group still had a good time in the limited setting I had created.  The experience taught me a lot about what players experience when playing role playing games and how my expectations differed wildly from the experience that they had.  As I continue to develop games, I look back at my time playing D&D and remind myself that, no matter what I do, the experience I craft will not necessarily be the same experience that the player has with my game.

My thoughts on running a Ludum Dare without the rating period

Over the past month or so, there has been a kerfuffle within the Ludum Dare community.  It seems like Mike Kasprzak has been unable to rectify the need to build a more current website for the community and the responsibility of hosting the next Ludum Dare challenge.  This has caused quite a few feathers to get ruffled in the comments section relating to any post relating to LD36.  Some people have been asking about keeping the voting in some capacity, while others have been threatening to not participate in protest.  Sometimes an internet community explodes about something that they have ignored when they could have had some real input.  I'm rather baffled by this phenomenon.

Don't get me wrong, I personally loved getting the ratings back from my work on any given game I submitted for the challenge.  Feedback in a convenient number form is highly informative (and intoxicating).  This should not, however, be the make or break condition for whether or not you enter the challenge.  If you are the type of developer that absolutely has to have the feedback of the community, you are chasing the popularity contest to the detriment of your game designs.  I've been guilty of this fallacy on occasion.  Those games that I have made in this mold are games that I am not proud of.  I'm not sure that those games I've played "inspired" by community ratings are any better than those truly original games submitted.

Most comments I've read protesting this (hopefully temporary) change boil down to this:  "I'm not happy because Mike's decision effects my plans!"  This does not contribute to the conversation at all.  More productive comments have been consistently bashed until those commenters simply stop contributing to the conversation about the future of Ludum Dare.  Not only is this non-productive, it's actively harmful to the community as a whole.  I've seen it happen before.  The hackerspace I founded was initially an open community where people would step up and volunteer for what needed to happen for the good of the space.  Now that same community is having extreme difficulty finding anyone to volunteer for anything, be it for classes or simply keeping the space clean.  Volunteerism died because the vocal minority was tearing down the community constantly.  Unfortunately, elements of that minority were in control of the 'space.  I'm seeing the same thing happen within the Ludum Dare community now.  If we let these elements control the conversation, we'll have lost the little nugget of gold that so many of us enjoy now.

Moreover, many of these "protesters" have been the late arrivals to the discussion and are now getting pissed about not being listened to a month after the decision was made.  That's like going to dinner late and not being happy about the menu.  You came in late.  You missed the planning and cooking stage, so you've lost the ability to change the cake now.  If this event is so important to you, you should have been more involved in helping out with it.  I haven't been involved in the community's maintenance, but I know that there is a way to join in helping out.  At least occasionally checking in with the community between numbered Dares would have clued you into the issues hosting the challenges.  If you don't like the direction now, get more involved in the future.

I'm assuming that most of this anger comes from a place of passion:  Passion for the Dares goes deep.  I got the bug my first Dare.  I know those that participate in a single challenge almost always have a good experience and want to participate further.  If you have passion for this Dare being great, stop sitting on the sidelines and join in making this game challenge community great!

Metris, Tetris and mutating known formulas

After sitting and waiting for the memories of the last Ludum Dare to fade a bit, especially the emotions, it's time to sit down and do some good, old-fashioned analysis on our game, Metris.  Metris is a mutation variant of Tetris, the classic block game.  Instead of the known formula of rotating shapes, we used morphing in place of it.  That was the core of our idea: morph the shapes in Tetris and use someone's existing codebase to kick off the jam a little faster than the last iterations.

We started the evening by brainstorming ideas until the two teams were decided: Our game, with two people working on it in Python, and the gobs of people working on the other game in Unity. It seems like my preferred language, Python, turns off quite a few developers.  Those not scared off by Python were not too enthusiastic about working on a Tetris clone.  Oh well, the game they came up with was good as well.

Once we had our game concept in mind, we found a code base to work from and started working on it.  At first, it seemed like the code we were using was good, but after a while, I found myself working on handling the edge cases that the original developer never bothered to handle.  I spent the entire first evening and most of the morning working on getting the edge cases under control.  Although it was a good lesson, I would have much rather have just spent some more time looking at code bases and not have dealt with the headache in the first place.  Lesson learned, I suppose.

I started feeling rather weathered as we entered the second evening.  Apparently I didn't avoid the cold that my significant other had brought home from work.  Despite that, I was still able to handle the rest of the edge cases in the code and get the game to run the way we wanted it to run.  I retired from working on the game early that night, knowing full well that the next day would be a mad rush yet again to get the game finished and polished.

We started doing the polishing phase once we started working on the final day of the jam.  We created a win condition, set up several levels for the game, and even got some music in as well!  Funnily enough, we started the day assuming that we would not be able to get music in for the game.  There just wasn't enough time to get both the polish in, along with working on the music.  In the final hours, Josh came in and wanted to do some audio for one of the groups.  Fortunately for us, the other group, which had seemingly absorbed any walk-ins, was at capacity when it came to audio people.  We sat him down for a quick playtest and some vague desires on what the game should sound like and we let him loose.  A mere hour later, he had music done and in the game for us.  Sweet!

Ok, now time for good, the bad and the ugly!

The Good:

• I got practice on working with a poorly documented, buggy code base other than my own.
• Metris has music!
• We got time to spend on polishing the game more than a few hours.  Consequently, the game was much more complete and looked better than the playable demo we had at the beginning.

The Bad:

• Not a lot of people joined us for creating this game.  This was not ideal, since there were over a dozen people working on the other one.  I think Unity has saturated the game development community.
• Getting sick.  Not much else to say about that.  Colds suck.

The Ugly:

•  My artwork.  Seriously, who let me do the artwork?  Oh, riiight.....

Ok, that's all for this segment.  At some point in the near future, I'll be taking a more formal look at the numbers and what the community had to say about the game.

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.